Secure tracking and transfer of items using a blockchain

ABSTRACT

Technologies are shown for tracking transfer of an item on an item tracking data blockchain, where transfers of the item and the holder of the item are recorded in item tracking data blocks of the blockchain. In some examples, a verification of the item is performed for a transfer and recorded in the data block for the transfer. In other examples, the blockchain stores a unique code for the ticket. Transfers of the ticket are recorded in the blockchain. When the ticket is presented for use, a holder identifier and a presented ticket code are validated against a holder identifier in the most recent block in the blockchain and the unique code for the ticket stored in the blockchain. In some examples, a portion of a resale price of the ticket is sent to an issuer of the ticket.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a divisional of U.S. patent application Ser. No.16/041,671, filed on Jul. 20, 2018, which claims the benefit of priorityto U.S. Provisional Patent Application No. 62/612,091, filed Dec. 29,2017. Each of the aforementioned applications is hereby incorporated byreference in its entirety.

BACKGROUND

It is challenging to be able to effectively track items and verify theirauthenticity, whether the items are physical or digital. For example,tracking the authenticity of an item, such as a vehicle part or a pieceof art, to ensure a chain of custody or to ensure authenticity of theitem through transfer from one entity to another. It is important toprevent items from being copied or counterfeited.

In another example, an event ticket may be transferred from a primaryissuer to a purchaser and transferred from one purchaser to another.Tracking the event ticket through multiple transfers to final use is achallenge. It is also important to prevent tickets from being copied orcounterfeited and that the tickets only be used once.

It is with respect to these and other considerations that the disclosuremade herein is presented.

SUMMARY

In some examples of the disclosed technology, a blockchain smartcontract (e.g., Etherum smart contract) is utilized that includesmethods for the tracking of provenance between transacting parties. Suchprovenance tracking substantially promotes efficiency of transaction,authenticity of the products/services/digital content, credibility oftransaction, mitigates disputes, and eliminates possible fraud. Inexamples of this aspect, a digital provenance smart contract block isassociated with one or more transactions of a product/service/digitalcontent. In certain examples, physical electronic tags, digital storagemechanisms, RFID tags, and other digital identification modalities canbe used to store/retrieve/process one or more provenance tracking smartcontract blocks.

Operatively, the provenance tracking of a source product, service, ordigital content being stored and/or transacted on an exemplary one ofthese platforms can be expressed as a blockchain smart contract havingtherein one or more provenance indicators, certificates, orauthenticators that detail the provenance history of the product,service, or digital content. In an illustrative implementation, theprovenance tracking data can reside on a physical storage deviceresident and/or associated with the source product/service/digitalcontent.

Operatively, the provenance block of the exemplary smart contract blockchain can also be verified by a third party to ensure the integrity ofthe provenance historical data. Illustratively, the third party can beone or more the original manufacturer/operator/owner/provider of thesource product/service/digital content.

In an example of another aspect of the disclosed technology, an issuerof an event ticket creates a blockchain smart contract representing theticket. Transfer of the ticket from one buyer to another is tracked inthe smart contract on the blockchain. A final buyer presents theircredentials at a venue to gain entry. The venue uses the final buyer'scredentials to validate that the final buyer owns the ticket on theblockchain and marks the ticket as used in the smart contract. Thedisclosed technology can support safe and traceable transfer of ticketsusing smart contracts on a blockchain, e.g. the Ethereum blockchain.

It should be appreciated that the above-described subject matter mayalso be implemented as a computer-controlled apparatus, a computerprocess, a computing system, or as an article of manufacture such as acomputer-readable medium. These and various other features will beapparent from a reading of the following Detailed Description and areview of the associated drawings. This Summary is provided to introducea selection of concepts in a simplified form that are further describedbelow in the Detailed Description.

This Summary is not intended to identify key features or essentialfeatures of the claimed subject matter, nor is it intended that thisSummary be used to limit the scope of the claimed subject matter.Furthermore, the claimed subject matter is not limited toimplementations that solve any or all disadvantages noted in any part ofthis disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The Detailed Description is described with reference to the accompanyingfigures. In the figures, the left-most digit(s) of a reference numberidentifies the figure in which the reference number first appears. Thesame reference numbers in different figures indicate similar oridentical items.

FIG. 1 is an architectural diagram showing an illustrative example of asystem for an item tracking data blockchain;

FIG. 2A is a data architecture diagram showing an illustrative exampleof an item tracking data blockchain securing item transfer transactions,where each transfer of an item is secured with a new tracking data blockon the blockchain;

FIG. 2B is a data architecture diagram showing another illustrativeexample of an item tracking data blockchain where each block on theblockchain records a transfer transaction for an item;

FIG. 2C is a data architecture diagram showing another illustrativeexample of an item tracking data blockchain pertaining to a ticket item,where each block on the blockchain records a transfer transaction forthe ticket

FIG. 3A is a data architecture diagram showing an illustrative exampleof an originator of an item creating an item tracking data blockchainfor tracking transfer transactions for the item through multipletransfers of the item, where the transactions can be validated;

FIG. 3B is a data architecture diagram showing an illustrative exampleof an item tracking data block on an item tracking data blockchain thatincludes code for methods for transferring items and completing transferof items tracked the item tracking data blockchain;

FIG. 3C is a data architecture diagram showing an illustrative exampleof a ticket issuer creating ticket tracking data blockchain for trackingtransfer transactions for the ticket through multiple transfers of theticket to final use at a venue;

FIG. 3D is a data architecture diagram showing an illustrative exampleof a ticket tracking data block on a ticket tracking data blockchainthat includes code for methods for transferring a ticket and using theticket at a venue;

FIG. 3E is a data architecture diagram showing an illustrative exampleof a ticket issuer creating ticket tracking data blockchain for trackingtransfer transactions for the ticket through multiple transfers of theticket to final use at a venue, where a portion of an increase in pricein a transfer can be sent to the issuer;

FIG. 3F is a data architecture diagram showing an illustrative exampleof a ticket tracking data block on a ticket tracking data blockchainthat includes code for methods for transferring a ticket andtransferring a portion of the an increase in price to the issuer as wellas using the ticket at a venue;

FIG. 4A is a control flow diagram showing an illustrative example of aprocess for an originator of an item or issuer of a ticket to create agenesis block for a blockchain to track the item or ticket;

FIG. 4B is a control flow diagram showing an illustrative example of aprocess for generating an item tracking data block on an item trackingdata blockchain for a transfer of an item;

FIG. 4C is a control flow diagram illustrating an example of a processfor provenance tracking for a product, service or digital content for atransfer on an item tracking data block;

FIG. 4D is a control flow diagram illustrating an example of a processfor transferring and using a ticket managed on a ticket tracking datablockchain;

FIG. 4E is a control flow diagram illustrating another example of aprocess for transferring and using a ticket managed on a ticket trackingdata blockchain, where a portion of an increase in ticket price is sentto an issuer of the ticket;

FIG. 4F is a control flow diagram illustrating still another example ofa process for transferring and using a ticket managed on a tickettracking data blockchain, where an issuer of the ticket creates a tokenon a blockchain for the ticket;

FIG. 4G is a control flow diagram illustrating an example of avalidation process for blocks added to the item or ticket tracking datablockchains distributed to untrusted nodes;

FIG. 5 is a data architecture diagram showing an illustrative example ofa user using an application programming interface to transfer and trackitems on an item tracking data blockchain;

FIG. 6A is a data architecture diagram illustrating a simplified exampleof a blockchain ledger based on the tracking data blocks of the itemtracking data blockchain of FIG. 1;

FIG. 6B is a data architecture diagram showing an illustrative exampleof smart contract code, transactions and messages that are bundled intoa block so that their integrity is cryptographically secure and so thatthey may be appended to a blockchain ledger;

FIG. 7 is a computer architecture diagram illustrating an illustrativecomputer hardware and software architecture for a computing systemcapable of implementing aspects of the techniques and technologiespresented herein;

FIG. 8 is a diagram illustrating a distributed computing environmentcapable of implementing aspects of the techniques and technologiespresented herein; and

FIG. 9 is a computer architecture diagram illustrating a computingdevice architecture for a computing device capable of implementingaspects of the techniques and technologies presented herein.

DETAILED DESCRIPTION

In the context of e-commerce, e-tailing, digital advertising, digitalmedia distribution and broadcast, sometimes, it is advantageous for theplatform operators that allow for the transaction ofproducts/services/digital content (including digital advertisement andsoftware) to have available a mechanism to track the provenance of thesourced products/services/digital content to provide more certainty tothe transacting parties of the authenticity of theproducts/services/digital content. Additionally, such provenancetracking can allow buyers of resold products to preserve the provenanceof purchased products/services/digital content to maintain/sustaincollectability, preserve pricing, and memorialize chain of custody amonga lineage of the owners of the products/services/digital content.Conventional e-commerce, e-tailing, digital advertising, digital mediadistribution and broadcast platforms can be deficient from memorializingand/or tracking the provenance of products/services/digital content asthey are transacted serially over time.

The following Detailed Description describes technologies for the use ofa blockchain in an item tracking data management system that maintainsprovenance data in item tracking data blocks on an item tracking datablockchain.

An item tracking data blockchain is established by an originator orsource of an item, such as a physical object or article, a service ordigital content, that represents the item. An item tracking data blockis created when the item is the subject of a transfer transaction andthe block is linked to the blockchain. Provenance of the item can bevalidated by another entity, such as the originator or a validationentity, to ensure authenticity of the item. In some examples, validationof provenance of an item can result in transfer of payment from thetransferee to the transferor. In some other examples, the item caninclude a physical electronic tag, digital storage mechanism,radio-frequency identifier (RFID) tag, or other digital identificationmodality that is stored in the item tracking data blockchain for theitem.

A technical advantage of the disclosed item tracking data technologyincludes securely maintaining provenance data on a blockchain that canbe publicly viewable and traceable. Another technical advantage of thedisclosed item tracking data technology is the distributed nature of theblockchain, which prevents an unauthorized entity from modifying orcorrupting the item tracking data at any single point.

The following Detailed Description also describes technologies for theuse of a blockchain in a ticket tracking data management system thatmaintains ticket transfer data in ticket tracking data blocks on aticket tracking data blockchain.

A ticket tracking data blockchain is established by an issuer of aticket, such as a ticket entitling a bearer of the ticket to enter avenue for an event or for a service. A ticket tracking data block iscreated when the ticket is the subject of a transfer transaction and theticket tracking data block is linked to the blockchain. A ticket can berepeatedly transferred and the transfer of the ticket maintained on theticket tracking data blockchain. When the ticket is presented for use,such as at an event venue, a venue device verifies the ticket based onthe ticket tracking data blockchain and marks the ticket as used toprevent reuse. In some examples, a portion of a resale price of theticket may be sent to the issuer of the ticket.

A technical advantage of the disclosed ticket tracking data technologyincludes securely maintaining a ticket on a blockchain to preventcounterfeiting and to permit the ticket to be publicly verified andtraced to prevent fraudulent transfers. Another technical advantage ofthe disclosed item tracking data technology is the distributed nature ofthe blockchain, which prevents an unauthorized entity from modifying orcorrupting the ticket tracking data at any single point.

Conventionally, items can be copied or counterfeited and then sold asauthentic items. In addition, used items can be offered as new ororiginal condition items. It can be difficult for a potential buyer ofan item to effectively determine whether an item is authentic ororiginal before purchasing. It is particularly difficult when apotential purchaser cannot inspect the item, such as when items areoffered for sale on-line through websites. If the potential buyer isuncertain about the provenance of an item, then the potential buyer maybe less inclined to purchase the item or may offer a lower pricereflecting their uncertainty.

Similarly, tickets, such as paper or electronic tickets, that arepurchased from an issuer are often resold. However, tickets are alsofrequently copied, counterfeited or used and, therefore, not valid foruse, e.g. not valid for entry to an event or for access to a service ordigital content corresponding to the ticket. It can be difficult for apotential purchaser to determine whether the ticket is valid beforepurchasing the ticket. In some cases, a buyer may only discover that aticket is invalid when the buyer presents the ticket for use. If thepotential buyer is uncertain about the validity of a ticket, then thepotential buyer may forego purchase of the ticket or may offer a lowerprice reflecting their uncertainty about the validity of the ticket.

In certain simplified examples of the disclosed technologies, a method,system or computer readable medium for provenance tracking is showninvolving generating, by an originator entity, a first item trackingdata block on an item tracking data blockchain. The first item trackingdata block stores data identifying an item, a holder identifier foridentifying a holder of the item and a validated indicator, where holderidentifier is set to an identifier of the originator entity for the itemand the validated indicator is set to a true state. Data in the firstitem tracking data block is signed with a first cryptographic digitalsignature of the originator entity. A first transferee entity generatesa second item tracking data block on the item tracking data blockchain.The second item tracking data block stores a holder identifier and avalidated indicator, where the holder identifier is set to an identifierof the first transferee entity and the validated indicator is set to thetrue state. The second item tracking data block is linked to the firstitem tracking data block and the second item tracking data block issigned with a second cryptographic digital signature of the originatorentity.

In an example of this aspect of the disclosed technology, the provenancetracking involves a second transferee entity generating a third itemtracking data block on the item tracking data blockchain. The third itemtracking data block stores a holder identifier and a validatedindicator, where the holder identifier is set to an identifier of thesecond transferee entity and the validated indicator is set to the falsestate. The third item tracking data block is linked to the second itemtracking data block. In response to receiving a verification messagefrom a third party, the validated indicator in the third item trackingblock is set to true. And the third item tracking data block is signedwith a cryptographic digital signature of the first transferee entity.The validated indicator in the third item tracking block can be set totrue responsive to receiving the verification message from thevalidation party and involve transferring payment for the item to thefirst transferee.

In some examples, the identifier of the originator entity is a publickey address for the originator entity, the identifier of the firsttransferee entity is a public key address for the first transfereeentity, and the identifier of the second transferee entity comprises apublic key address for the second transferee entity. Also, the firstcryptographic digital signature of the originator entity can bepartially based on data within the first item tracking data block, thesecond cryptographic digital signature of the originator entity can bepartially based on data within the second item tracking data block, andthe cryptographic digital signature of the first transferee entity canbe partially based on data within the third item tracking data block.

In an example of another aspect of the disclosed technology, tickettracking involves an issuer entity generating a first ticket trackingdata block on a ticket tracking data blockchain. The first tickettracking data block stores a unique code value for the ticket, a holderidentifier for identifying a holder of the ticket and a used indicator,where holder identifier is set to an identifier of the issuer entity forthe ticket and the used indicator is set to a false state. The firstticket tracking data block is signed with a first cryptographic digitalsignature of the issuer entity. A first transferee entity generates asecond ticket tracking data block on the ticket tracking datablockchain. The second ticket tracking data block store a holderidentifier, the unique code value for the ticket, and a used indicator,where the holder identifier is set to an identifier of the firsttransferee entity and the used indicator is set to the false state. Thesecond ticket tracking data block is linked to the first ticket trackingdata block and signed with a second cryptographic digital signature ofthe issuer entity.

In some examples of this aspect of the disclosed technology, if the usedindicator is set to the false state, a second transferee entitygenerates a third ticket tracking data block on the ticket tracking datablockchain. The third ticket tracking data block stores a holderidentifier, the unique code value for the ticket, and a used indicator,where the holder identifier is set to an identifier of the secondtransferee entity and the used indicator is set to the false state. Thethird ticket tracking data block is linked to the second ticket trackingdata block and signed with a cryptographic digital signature of thefirst transferee entity.

In certain examples of this aspect of the disclosed technology, apresented code value is received from the second transferee entity. Ifthe used indicator stored in the third ticket tracking data block is setto the false state and the presented code value corresponds to theunique code value stored in the third ticket tracking data block, thenthe ticket is indicated as valid and the used indicator is set to thetrue state.

In still other examples of this aspect of the disclosed technology, thesecond ticket tracking data block stores a price value that is set tothe first transfer price from the issuer entity to the first transfereeentity. When the third ticket tracking data block is generated, adetermination is made as to whether a second transfer price for thetransfer from the first transferee entity to the second transfereeentity is greater than the first transfer price. If the second transferprice is greater than the first transfer price, then a payment is sentfrom the first transferee to the issuer entity.

Yet another aspect of the disclosed technology involves tracking aticket on a ticket tracking data blockchain, where the ticket trackingdata blockchain stores a unique code value for the ticket, a holderidentifier for identifying a holder of the ticket and a used indicatorindicating whether the ticket has been used. This aspect involvesgenerating a first ticket tracking data block on a ticket tracking datablockchain if the used indicator indicates that the ticket has not beenused. The first ticket tracking data block stores an identifier of afirst transferee entity in a holder identifier of the first tickettracking data block. The first ticket tracking data block is linked to aprevious ticket tracking data block on the ticket tracking datablockchain and signed with a cryptographic digital signature of atransferor entity identified in the holder identifier stored in theprevious ticket tracking data block.

Some examples of this aspect of the disclosed technology includegenerating a second ticket tracking data block on the ticket trackingdata blockchain responsive to a second transfer request if the usedindicator indicates that the ticket has not been used. The secondidentifier ticket tracking data block stores an identifier of a secondtransferee entity in the holder identifier. The second ticket trackingdata block is linked to a first ticket tracking data block on the tickettracking data blockchain and signed with a cryptographic digitalsignature of the first transferee entity identified in the holderidentifier stored in the first ticket tracking data block.

Certain examples of this aspect of the disclosed technology involvereceiving a presented holder identifier and a presented code value. Ifthe used indicator indicates that the ticket has not been used, thepresented holder identifier corresponds to the holder identifier in thea most recent ticket tracking data block in the ticket tracking datablockchain, and the presented code value corresponds to the unique codevalue stored in the ticket tracking data blockchain, then the ticket isindicated as valid and the used indicator in the ticket tracking datablockchain is set to indicate that the ticket has been used.

Yet other examples of this aspect of the disclosed technology involvedetermining whether a second transfer price value for the transfer fromthe first transferee entity to the second transferee entity is greaterthan the first transfer price value and, if the second transfer pricevalue is greater than the first transfer price value, send a paymentfrom the first transferee to an issuer entity.

As will be described in more detail herein, it can be appreciated thatimplementations of the techniques and technologies described herein mayinclude the use of solid state circuits, digital logic circuits,computer components, and/or software executing on one or more inputdevices. Signals described herein may include analog and/or digitalsignals for communicating a changed state of the data file or otherinformation pertaining to the data file.

While the subject matter described herein is presented in the generalcontext of program modules that execute in conjunction with theexecution of an operating system and application programs on a computersystem, those skilled in the art will recognize that otherimplementations may be performed in combination with other types ofprogram modules. Generally, program modules include routines, programs,components, data structures, and other types of structures that performparticular tasks or implement particular abstract data types. Moreover,those skilled in the art will appreciate that the subject matterdescribed herein may be practiced with other computer systemconfigurations, including multiprocessor systems, mainframe computers,microprocessor-based or programmable consumer electronics,minicomputers, hand-held devices, and the like.

By the use of the technologies described herein, an item or tickettracking data blockchain is used to securely maintain data on ablockchain that can be widely distributed and accessed. In an itemtracking data blockchain, item tracking data blocks securely maintainprovenance data for an item, such as an object, a service or digitalcontent, in a manner that provides wide access to the data so that theprovenance of the item can be readily traced by many users who haveaccess to the blockchain. In a ticket tracking data blockchain, theticket tracking data blockchain represents the ticket and the tickettracking data blocks track transfer of the ticket from issuance to usein a manner that provides wide access to the ticket transfer data tousers so that the validity of the ticket can be readily establishedusing secure, widely available information from the blockchain. Forincreased transparency, code for transferring an item or ticket can beincluded in the item or ticket tracking data blocks

Other technical effects other than those mentioned herein can also berealized from implementation of the technologies disclosed herein.

In the following detailed description, references are made to theaccompanying drawings that form a part hereof, and in which are shown byway of illustration specific configurations or examples. Referring nowto the drawings, in which like numerals represent like elementsthroughout the several figures, aspects of a computing system,computer-readable storage medium, and computer-implemented methodologiesfor an item tracking data blockchain ledger will be described. As willbe described in more detail below with respect to the figures, there area number of applications and services that may embody the functionalityand techniques described herein.

FIG. 1 is an architectural diagram showing an illustrative example of anitem or ticket tracking system 100 utilizing an item or ticket trackingdata blockchain 140. An item tracking data blockchain can be utilized tosecurely maintain data pertaining to the provenance of an item, such asan object, service or digital content, and track transfers of the item.A ticket tracking data blockchain can be utilized to securely distributea ticket, such as a ticket for an event or a service, and tracktransfers of the tickets from issuance to use. In the embodiment of FIG.1, blockchain 140 can be a publicly available blockchain that supportsscripting, such the ETHEREUM blockchain, which supports a SOLIDIFYscripting language, or BITCOIN, which supports a scripting languagecalled SCRIPT.

An item originator or ticket issuer device 110 initiates item or tickettracking data blockchain 140 by creating genesis block 142A. For an itemtracking data blockchain, genesis data block 142A, in this example, caninclude information identifying an item, such as a unique serial numberor tracking number, and information identifying the originator. Otherdescriptive data for the item, such as manufacturer, part number, dateof manufacture, color, size, etc., can also be included in genesis datablock 142A in some applications. In other applications, the genesis datablock 142A may include the item itself, such as a digital audio, videoor photo file.

For a ticket tracking data blockchain, genesis data block 142A, in oneexample, can include a code, key or token value that constitutes theticket itself. In some examples, the genesis data block 142A can includeinformation relating to the ticket, such as information identifying theissuer, the date of the event or service, the venue or service provider,or a seat or box location. In other examples, the ticket may represent aservice, such as a gift certificate for a massage or haircut, andgenesis data block 142A can include information relating to the service,such as the service provider, valid dates for the service, or adescription of the included service or services.

In some embodiments, the item originator or ticket issuer device 110 maybe replaced by another computing node, such as a computer on apeer-to-peer network, or other computing device.

In the example of FIG. 1, the item information or ticket is provided byitem originator or ticket issuer device 110 and secured on item orticket tracking data blockchain 140. The information in the data blocks142 of the blockchain can be made accessible to other entities, such asclient/servers 120A, 120B or 120C or blockchain platform 130. In thisexample, the client/servers 120 can communicate with item originator orticket issuer device 110 as well as a network of servers for blockchainplatform 130 that supports and maintains blockchain 140. For example,the ETHERIUM blockchain platform from the ETHERIUM FOUNDATION ofSwitzerland provides a decentralized, distributed computing platform andoperating system that provides scripting functionality.

In one example, an item originator device 110 owns and controls the datablocks 142 in item tracking data blockchain 140 and can verify orvalidate transfers of the item represented by the item tracking datablocks 142B, 142C, 142D and 142E. In another example, a validationdevice 112, which can represent an authorized entity such as a certifiedappraiser or authorized seller, distributor or technician, can verify orvalidate the transfers represented by the item tracking data blocks142B, 142C, 142D and 142E. There can be multiple authorized entitiesthat can each utilize a validation device 112. The item tracking datablocks 142 can, in some examples, include metadata identifying entitiesthat are authorized to verify or validate transfers of the item.

In another example, a ticket issuer device 110 owns and controls thegenesis block 142A that is the ticket, but other entities, such asbuyers utilizing client/server devices 120, can verify or validatetransfers of the ticket represented by the ticket tracking data blocks142B, 142C, 142D and 142E, e.g. a seller entity who holds the ticket canvalidate a transfer to a buyer entity when the seller entity confirmspayment. In this example, a venue device 114, which represents a venueor service provider for the ticket, can mark the ticket as used when aholder of the ticket represented by the ticket tracking data blockchain140 presents the ticket for use. There can be multiple venue devices 114that can receive presentation of the ticket, such as handheld scanningdevices utilized by ticket takers at the venue or service provider.

Although item originator or ticket issuer device 110, at leastinitially, maintains control over the item or ticket, the item or tickettracking data blockchain 140 can be made accessible to other entities,such as client/servers 120, so these entities can trace the data in theblockchain to examine the validity of the item or ticket. For example,item or ticket tracking data blockchain 140 may be viewable to thepublic through the use of applications that can access blockchaininformation. By providing access to the item tracking data blockchain140, this approach allows users to rely on the authenticity of the datafile that is maintained on the item tracking data blockchain 140 underthe control of the file owner, e.g. the user of item originator orticket issuer device 110.

In another example, the item or ticket tracking data blockchain 140 maybe restricted to being viewable only to entities that are authorized toaccess the blockchain 140, such as validation device 112 or venue device114. By restricting access to the blockchain 140, an item originator orticket issuer can preserve greater control over the item or ticket, suchas limiting resale of the item or ticket to authorized entities.

FIG. 2A is a data architecture diagram illustrating a simplified exampleof an item or ticket tracking data blockchain ledger 200 based on theblocks 142A-E of the item or ticket tracking data blockchain ledger 140of FIG. 1. The item or ticket tracking data blockchain ledger 200example of FIG. 2A is simplified to show block headers, metadata andsignatures of blocks 210A-E in order to demonstrate transfers of an itemor ticket that are traceable and secure using a blockchain. In outline,a blockchain ledger may be a globally shared transactional database.Signatures can, in some examples, involve all or part of the data storedin the data the blocks 142A-E and can also involve public key addressescorresponding to entities involved in the transfers, e.g. an originatorentity, a transferor entity, or a transferee entity.

The blockchain ledger 200 may be arranged as a Merkle tree datastructure, as a linked list, or as any similar data structure thatallows for cryptographic integrity. The blockchain ledger 200 allows forverification that provenance data or a ticket has not been corrupted ortampered with because any attempt to tamper will change a MessageAuthentication Code (or has) of a block, and other blocks pointing tothat block will be out of correspondence. In one embodiment of FIG. 2A,each block may point to another block. A block may comprise one or moretransactions. Each block may include a pointer to the other block, and ahash (or Message Authentication Code function) of the other block.

Each block in the blockchain ledger may optionally contain a proof datafield. The proof data field may indicate a reward that is due. The proofmay be a proof of work, a proof of stake, a proof of research, or anyother data field indicating a reward is due. For example, a proof ofwork may indicate that computational work was performed. As anotherexample, a proof of stake may indicate that an amount of cryptocurrencyhas been held for a certain amount of time. For example, if 10 units ofcryptocurrency have been held for 10 days, a proof of stake may indicate10*10=100 time units have accrued. A proof of research may indicate thatresearch has been performed. In one example, a proof of research mayindicate that a certain amount of computational work has beenperformed—such as exploring whether molecules interact a certain wayduring a computational search for an efficacious drug compound.

The blocks 210 of item or ticket tracking data blockchain 200 in theexample of FIG. 2A shows transfers of the item or ticket secured with anew item or ticket tracking data block on the blockchain. In oneexample, item originator device 110 of FIG. 1 provides identifying anddescriptive provenance data for an item when it creates genesis datablock 210A. In another example, ticket issuer device 110 of FIG. 1provides a unique identifier for a ticket, such as a code, key or token,when it creates genesis data block 210A. The item originator or ticketissuer device 110 signs the genesis block 210A and the blockchain systemwithin which blockchain 200 is created verifies the genesis data blockbased on a proof function.

Note that a variety of approaches may be utilized that remain consistentwith the disclosed technology. In some examples relating to provenanceof an item, the item originator device 110 is a required entity or theonly entity permitted to verify or validate item tracking data blocks142 on the blockchain. In other examples, other entities, such asauthorized entities, can verify or validate item tracking data blocks.

In some examples involving tracking tickets, the ticket issuer device110 is a required entity to verify or validate ticket tracking datablocks 142 for transfer of the ticket to other entities. In otherexamples, the ticket issuer device 110 issues the ticket genesis datablock 142A, but other entities, e.g. transferors and transferees, canverify or validate ticket tracking data blocks 142 for transfer of theticket. In still other examples, only authorized entities, e.g.authorized ticket brokers or resellers, can verify or validate tickettracking data blocks 142.

In the example of FIG. 2A, transaction data for a transfer transaction,such as a public key or other identifier for a transferee, is stored inthe item/ticket tracking data blocks 142. Other transfer data that canbe included is the date of transfer, the transfer price, a validating orverifying entity, or other information. To record a first transfer, e.g.from the originator/issuer to ownerA, on the item/ticket tracking datablockchain ledger 200, item originator or ticket issuer device 110 or atransferor or transferee entity using, for example, client/servers 120,creates item or ticket tracking data block 210B, which identifies atransfer, e.g. transferA, and a transferee, e.g., ownerA, and linksblock 210B to block 210A. The item originator or ticket issuer device110 signs tracking data block 210B and commits block 210B to blockchain200 for verification by the blockchain platform.

For a second transaction, from ownerA to ownerB in this example, ownerB,e.g. using a client/server device 120, creates item/ticket tracking datablock 210C to secure transfer of the item or ticket from ownerA andlinks block 210C to block 210B. In the case of an item transfer,depending upon the implementation, data bock 210C can be signed by theoriginator entity, e.g. using originator device 110, a validationentity, e.g. using validation device 112, or ownerA, using aclient/server device 120, or some predetermined combination of two ormore of these entities. For example, the item tracking data block 210Ccan be configured to require a signature from the transferee ownerB andeither the originator entity or a validation entity.

In the case of a ticket transfer, depending upon the implementation,data bock 210C can be signed by the issuer entity, e.g. using issuerdevice 110, a validation entity, e.g. a ticket broker entity usingvalidation device 112, or transferor, e.g. ownerA, using a client/serverdevice 120, or some predetermined combination of two or more of theseentities. For example, the item tracking data blocks 210 can beconfigured to require a signature from the transferor ownerA and eitherthe issuer entity or a validation entity. In another example, the tickettracking data blocks 210 can be configured to require a signature fromthe transferee ownerB and either the issuer entity or a validationentity. In still another example, the ticket tracking data blocks 210can be configured to simply require a signature from the transferorownerA to effect the transfer.

Similarly, to record a transfer from ownerB to ownerC, tracking datablock 210D is created, e.g. by ownerC, linked to tracking data block210C, and signed as described above. Likewise, to record a transfer fromownerC to ownerD, tracking data block 210E is created, e.g. by ownerD,linked to tracking data block 210D, and signed as described above. Inthis approach, provenance of an item or validity of a ticket supportedby blockchain 200 can be confirmed by tracing the transaction recordedin each of tracking data blocks 210B, 210C, 210D and 210E back to thegenesis data block 210A.

FIG. 2B is a data architecture diagram showing another illustrativeexample of an item tracking data blockchain 240, where the item trackingdata blocks 242 include block state indicating a current holder or ownerof the item, e.g. a public key for the current owner entity, along witha payment required indicator, a payment amount indicator, and avalidated indicator. To establish blockchain 240 for an item, itemoriginator device 110 creates genesis item tracking data block 242A,which identifies the item that the block represents, indicates theoriginator entity, e.g. a public key or other identifier for theoriginator entity, as the holder, indicates that no payment is required,indicates that the payment amount is null, and indicates that the itemis validated, e.g. by the originator entity.

Note that the item can include an identification modality, such as aphysical electronic tag, bar code label, digital storage mechanism,radio-frequency identifier (RFID) tag, or other digital identificationmodality, that is stored in the item tracking data blockchain for theitem. The identification modality, in some examples, can be used tovalidate the item.

To transfer the item from the originator to TransfereeA, item originatordevice 110 or transferee entity TransfereeA, depending upon theimplementation, creates item tracking data block 242B, which indicatesTransfereeA, e.g. a public key or other identifier for the TransfereeAentity, as the holder, indicates that payment is required, e.g.payment_req(YES), indicates that the payment amount is A, e.g.payment_amt(A), and indicates that the item needs to be validated, e.g.validated(FALSE). In this example, because the item is being transferredfrom the custody of originator entity who knows that the item isauthentic, the originator entity block 242B as validated, e.g.validated(TRUE). When payment of payment amount A by TransfereeA isconfirmed, the originator entity changes the payment required field inblock 242B to indicate no payment is required, e.g. payment_req(NO), andsigns block 242B.

Similarly, to transfer the item from TransfereeA to TransfereeB,TransfereeB, in this example, creates item tracking data block 242C,which indicates TransfereeB, e.g. a public key or other identifier forthe TransfereeB entity, as the holder, indicates that payment isrequired, e.g. payment_req(YES), indicates that the payment amount is B,e.g. payment_amt(B), and indicates that the item needs to be validated,e.g. validated(FALSE).

In this example, because the item is being transferred from onetransferee to another, block 242C is validated by the originator entityor a validation entity, who inspects the item to verify that it isauthentic. As noted above, the item can include an identificationmodality, such as a physical electronic tag, bar code label, digitalstorage mechanism, radio-frequency identifier (RFID) tag, or otherdigital identification modality, that is stored in the item trackingdata blockchain for the item. The identification modality, in someexamples, can be used to validate the item. For example, the originatorentity or validation entity, or a device associated with the originatorentity or validation entity, can scan the identification modality toverify provenance.

If the item passes inspection, then the inspecting entity, e.g. theoriginator entity or validation entity, marks block 242C as validated,e.g. validated(TRUE). When payment of payment amount B by TransfereeB isconfirmed, TransfereeA changes the payment required field in block 242Cto indicate no payment is required, e.g. payment_req(NO), and signsblock 242C. In some implementations, block 242C can also be signed bythe originator entity or validation entity.

Item tracking data block 242D similarly secures another transfertransaction from TransfereeB to TransfereeC. Item tracking data block242E secures still another transferee transaction from TransfereeC toTransfereeD. In some implementations, each of the tracking data blocks242 is signed by the item originator device 110 and committed to theblockchain 240 for verification by the blockchain platform.

FIG. 2C is a data architecture diagram showing another illustrativeexample of a ticket tracking data blockchain 260, where the tickettracking data blocks 262 include block state indicating a current holderor owner of the ticket, e.g. a public key for the current owner entity,along with a current price field, a venue key, e.g. venue_key(KEY),which, in this example, permits a holder of the ticket to enter a venue,and a used indicator. To establish blockchain 260 for ticket, issuerdevice 110 creates genesis ticket tracking data block 262A, whichidentifies the ticket that the block represents, such as by thevenue_key(KEY) value, indicates the issuer, e.g. a public key or otheridentifier for the issuer entity, as the holder, indicates the currentprice as the original price of the ticket, e.g. current_price(ORIGINAL),and indicates that the ticket has not been used, e.g. used(FALSE). Notethat the venue key value can be encrypted, signed or otherwise cipheredin a manner that permits the issuer entity to verify that the ticket isvalid, but prevents counterfeiters or other malicious actors fromobtaining the valid venue key secured on blockchain 260.

To transfer the item from the originator to TransfereeA, issuer device110 or transferee entity TransfereeA, depending upon the implementation,creates ticket tracking data block 262B, which indicates TransfereeA,e.g. a public key or other identifier for the TransfereeA entity, as theholder, indicates that the ticket is being transferred at the originalprice, e.g. current_price(ORIGINAL), includes the venue_key(KEY), andindicates that the ticket has not been used. When payment of originalprice by TransfereeA is confirmed, the issuer entity signs block 262B tocomplete transfer of the ticket to TransfereeB.

Similarly, to transfer the ticket from TransfereeA to TransfereeB, inthis example, TransfereeB creates ticket tracking data block 262C, whichindicates TransfereeB, e.g. a public key or other identifier for theTransfereeB entity, as the holder, indicates the current price, e.g.current_price(B), includes the venue_key(KEY), and indicates that theticket has not been used. When payment of the current price byTransfereeB is confirmed, TransfereeA signs block 262B to completetransfer of the ticket to TransfereeB.

Ticket tracking data block 262D similarly secures another tickettransfer transaction from TransfereeB to TransfereeC at current price C.Ticket tracking data block 262E secures still another transfereetransaction from TransfereeC to TransfereeD at current price D. In someimplementations, each of the tracking data blocks 262 is also signed bythe issuer device 110 or an authorized broker entity and committed tothe blockchain 260 for verification by the blockchain platform.

When the current holder of the ticket, TransferreeD in this example,presents the ticket to a venue device 114 at the venue, the venue deviceverifies the ticket and marks ticket tracking data block 262E as used,e.g. used(TRUE). For example, TransferreeD uses client/server device120A to present venue_key(KEY) in the form of a bar code that is scannedby venue device 114, which verifies that the KEY value is valid.

An item tracking data blockchain, such as blockchain 140 in FIG. 1 orblockchain 240 in FIG. 2B, enables provenance information for an item tobe securely stored and tracked through multiple transfers of ownershipof the item. FIG. 3A is a data architecture diagram showing a simplifiedillustrative example of the use of an item tracking data blockchain forsecurely storing provenance information for an item. In this example, anitem is transferred from an originator entity using originator device110 to a TransferreeA entity using client/server entity 120A.Subsequently, the item is transferred from TransfereeA to a TransfereeBentity who uses client/server entity 120B. A validation entity usingvalidation device 112 is used to validate the transfer from TransfereeAto TransfereeB.

In this illustrative scenario 300 and as described above, at 302,genesis block 242A is created by item originator device 110 with theoriginator entity as holder and the block marked as validated, e.g.validated(TRUE). FIG. 3B provides an example of an item tracking datablock 242 with methods defined for interacting with the block.

To transfer the item from the originator to TransfereeA, in thisexample, at 310, TranfereeA, using client/server 120A, creates itemtracking data block 242B, which indicates TransfereeA as the holder,payment is required, an amount of payment A, and validation is needed,and links block 242B to block 242A. When payment of the payment amount,e.g. payment_amt(A), is confirmed, originator device 110, at 304, inthis example, sets payment_req to FALSE, sets validated to TRUE, andsigns item tracking data block 242B to commit the transfer toTransfereeA. Once the transfer is committed, the blockchain platform forthe blockchain verifies block 242B, which is added to all copies of theblockchain 240.

To transfer the item from the TransfereeA to TransfereeB, in thisexample, at 314, TranfereeB, using client/server 120B, creates itemtracking data block 242C, which indicates TransfereeB as the holder,payment is required, an amount of payment B, and validation is needed,and links block 242C to block 242B. At 306, a validation entity usingvalidation device 112, after having confirmed the authenticity of theitem, sets validated to TRUE and, in this example, signs data in itemtracking data block 242B, such as data relating to the validated field.When payment of the payment amount, e.g. payment_amt(B), is confirmed,Transferree A, at 312, sets payment_req to FALSE, and signs data in itemtracking data block 242B, such as data relating to the payment_reqfield, to commit the transfer to TransfereeB. Once the transfer iscommitted, the blockchain platform for the blockchain verifies the block242C, which is added to all copies of the blockchain 240.

In the example of FIG. 3A, the provenance of the item can be obtained bytracing the blocks of item tracking data blockchain 240 to the genesisblock 242A. The disclosed technology enables the item provenance data tobe securely stored and traced on the item tracking data blockchain 240.The blockchain 240 can be made widely accessible for review, such as bypotential purchasers or users. The signatures in each of the blocks 242ensures the authenticity of the provenance data and transfers.

Scripts for transfer of an item and completion of a transfer transactioncan be secured by the item tracking data blocks 242 of item trackingdata blockchain 240 and executed by the operating system of thedecentralized, distributed blockchain platform. FIG. 3B is a dataarchitecture diagram showing an illustrative example of item trackingdata block 242 that includes the Transfer and Complete scripts. Alsoshown is a process 320 in a blockchain environment that creates an itemtracking data block 242. An example of block state 322 defined for theitem tracking data blocks 242 is also shown.

In this example, the Transfer script is called by a transferee with anidentifier for the item, e.g. provenanceID. The Transfer script invokesa function validateProvenance( ) to call a third party verificationenvironment to validate the item for the transaction and set up paymentto the transferor. In this example, the transferee calls the Completescript to complete the transfer of payment to the transferor.

FIG. 3C is a data architecture diagram showing a simplified illustrativeexample of the use of a ticket tracking data blockchain 260 for securelytracking transfers of a ticket on the blockchain. In this example,ticket is transferred from an issuer entity using issuer device 110 to aTransferreeA entity using client/server entity 120A. Subsequently, theticket is transferred from TransfereeA to a TransfereeB entity who usesclient/server entity 120B. A venue entity using venue device 114 is usedto validate the ticket upon presentation by TransfereeB and mark theticket as used.

In this illustrative scenario 330 and as described above, at 332,genesis block 262A is created by issuer device 110 with the issuerentity as the holder, e.g. holder(ISSUER), the venue key for the ticket,e.g. venue_key(KEY), and the block is marked as not used, e.g.used(FALSE). FIG. 3D provides an example of a ticket tracking data block262 with methods defined for interacting with the blocks 262.

To transfer the ticket from the issuer to TransfereeA, in this example,at 336, TransfereeA, using client/server 120A, creates ticket trackingdata block 262B, which indicates TransfereeA as the holder and linksblock 262B to block 262A. The issuer entity 110, at 334, signs block262B to confirm the transfer and commit block 262B to blockchain 260.For example, issuer entity can sign block 262B once it confirms payment.Once the transfer is committed, the blockchain platform for theblockchain verifies block 262B, which is added to all copies of theblockchain 260.

To transfer the ticket from the TransfereeA to TransfereeB, in thisexample, at 340, TransfereeB, using client/server 120B, creates tickettracking data block 262C, which indicates TransfereeB as the holder andlinks block 262C to block 262B. At 338, TransfereeA signs block 262C toconfirm the transfer and commit block 262C to blockchain 260. Forexample, TransfereeA can sign block 262C once it confirms payment. Oncethe transfer is committed, the blockchain platform for the blockchainverifies block 262C, which is added to all copies of the blockchain 260.

In this example, TransfereeB, using client/server 120B, at 342, presentsthe ticket to a venue or service provider entity using venue device 114.Venue device 114, confirms the validity of the ticket usingvenue_key(KEY) and, at 344, sets the used field to TRUE so that theticket cannot be reused.

In the example of FIG. 3C, the validity of the ticket can be confirmedby tracing the blocks 262 of ticket tracking data blockchain 260 to thegenesis block 262A. The disclosed technology enables the ticket to besecurely stored and transferred on the ticket tracking data blockchain260. The blockchain 260 can be made widely accessible for review, suchas by potential purchasers, to confirm validity of the ticket. Thesignatures in each of the blocks 262 ensures the authenticity of theticket and transfers.

Scripts for transfer and use of a ticket can be secured by the tickettracking data blocks 262 of ticket tracking data blockchain 260 andexecuted by the operating system of the decentralized, distributedblockchain platform. FIG. 3D is a data architecture diagram showing anillustrative example of ticket tracking data block 262 that includes theTransfer and Use scripts. Also shown is a process 350 in a blockchainenvironment that creates a ticket tracking data block 262. An example ofblock state 352 defined for the ticket tracking data blocks 262 is alsoshown.

In this example, the Transfer script is called by a transferee with anidentifier for the ticket, e.g. ticketID, an identifier for the seller,e.g. a public key address for the transferor entity, and an identifierfor the buyer, e.g. a public key address for the transferee. If theticket has not been used, e.g. ticketID.used==FALSE, and the selleridentifier matches the ticket holder, e.g. seller==ticket[id].holder,then, in this example, the Transfer script invokes a functionvalidateTransfer( ) to validate the venue_key and, if the key is valid,set the buyer as the current holder of the ticket, e.g.ticket[id].holder=buyer.

The Use script is called by a venue device with the identifier for theticket, e.g. ticketID, an identifier for the presenter, e.g. a publickey address for the entity presenting the ticket, and the venue_keyvalue as presented by the presenter. If the caller is the venue, thepresenter is the holder, e.g. presenter==ticket[id].holder, and thepresented venue_key matches the ticket venue_key value, e.g.venue_key==ticket[id].venue_key, then the venue device 114 sets the usedfield for the ticket to TRUE.

FIG. 3E is a data architecture diagram showing another simplifiedillustrative example of the use of a ticket tracking data blockchain 260for securely tracking transfers of a ticket on the blockchain and alsotracking a current price of the ticket so that a portion of an increasein ticket price can be sent to the issuer entity. In this example, theticket is transferred at an ORIGINAL price from an issuer entity usingissuer device 110 to a TransfereeA entity using client/server entity120A. Subsequently, the ticket is transferred from TransfereeA to aTransfereeB entity who uses client/server entity 120B at a new price B,which is higher than the ORIGINAL price resulting in a transfer of aportion of the price increase to the issuer. A venue entity using venuedevice 114 is used to validate the ticket upon presentation byTransfereeB and mark the ticket as used.

In this illustrative scenario 360 and as described above, at 362,genesis ticket tracking data block 262A is created by issuer device 110with the issuer entity as the holder, e.g. holder(ISSUER), the currentprice of the ticket, e.g. current_price(ORIGINAL), the venue key for theticket, and the block is marked as not used, e.g. used(FALSE). FIG. 3Fprovides an example of a ticket tracking data block 262 with methodsdefined for interacting with the blocks 262.

To transfer the ticket from the issuer to TransfereeA at the ORIGINALprice, in this example, at 366, TransfereeA, using client/server 120A,creates ticket tracking data block 262B, which indicates TransfereeA asthe holder with current_price(ORIGINAL) and links block 262B to block262A. The issuer entity 110, at 363, signs block 262B to confirm thetransfer and commit block 262B to blockchain 260. For example, issuerentity can sign block 262B once it confirms payment. Once the transferis committed, the blockchain platform for the blockchain verifies block262B, which is added to all copies of the blockchain 260.

To transfer the ticket from the TransfereeA to TransfereeB at price B,in this example, at 370, TransfereeB, using client/server 120B, createsticket tracking data block 262C, which indicates TransfereeB as theholder with the current_price(B) and links block 262C to block 262B. At368, TransfereeA signs block 262C to confirm the transfer and commitblock 262C to blockchain 260. For example, TransfereeA can sign block262C once it confirms payment. In this example, a method executes forticket tracking data block 262C that determines a portion of thecurrent_price(B) to be sent to the issuer entity and, at 364, sends thisportion to the issuing entity. Once the transfer is committed, theblockchain platform for the blockchain verifies block 262C, which isadded to all copies of the blockchain 260.

In this example, TransfereeB, using client/server 120B, at 372, presentsthe ticket to a venue or service provider entity using venue device 114.Venue device 114, confirms the validity of the ticket usingvenue_key(KEY) and, at 374, sets the used field to TRUE so that theticket cannot be reused.

FIG. 3F is a data architecture diagram showing an illustrative exampleof ticket tracking data block 262 that includes the Transfer and Usescripts. Also shown is a process 380 in a blockchain environment thatcreates a ticket tracking data block 262. An example of block state 382defined for the ticket tracking data blocks 262 is also shown. Theexample of FIG. 3F is similar to the example of FIG. 3D but with theaddition of code in the Transfer script that determines whether theprice of the ticket has increased and sends a portion of the increasedprice to the issuer of the ticket. In other examples, a fixed retransferfee can be sent to the ticket issuer for each transfer of the ticket.Other variations are possible without departing from the scope of thedisclosed technology.

FIG. 4A is a control flow diagram showing an illustrative example of aprocess 400 for creating a genesis block for securely storing provenancedata for an item on an item tracking data blockchain in accordance withone aspect of the disclosed technology or representing a ticket on aticket tracking data blockchain in accordance with another aspect of thedisclosed technology.

In the case of an item tracking data blockchain, this example involvescreating a genesis block, at 404, for an item that identifies the itemand an originator of the item. In some examples, the genesis block mayinclude information identifying a serial number unique to the item, apart number for the item, a manufacturer of the item, a manufacturingdate, or descriptive information such as size, color, appearance, etc.

In the case of a ticket tracking data blockchain, the genesis blockcreated at 404 can include information such as an identifier for theticket, a unique key value for verifying the ticket, a price, a date, avenue, access limitations, seating, etc.

At 406, the genesis block is ciphered and signed to commit the genesisblock to the item or ticket tracking data blockchain, such as item orticket tracking data blockchain 140 in FIG. 1, item tracking datablockchain 240 of FIG. 2B, or ticket tracking data blockchain 260 ofFIG. 2C.

FIG. 4B is a control flow diagram showing an illustrative example of aprocess 410 for tracking transfer of an item on an item tracking datablockchain. At 412, an item transfer request is received by a blockchainplatform supporting the item tracking data blockchain, such as a requestto create an item tracking data block from client/server 120A in FIG.3A.

At 414, an item tracking data block, e.g. item tracking data block 242Bin FIG. 3A, is generated for the item transfer and linked to the itemtracking data blockchain, i.e. the new item tracking data block islinked to the previous block in the blockchain. The item transfer datablock includes an identifier for the transferee of the transaction, e.g.TransfereeA in FIG. 3A.

At 416, in this example, the provenance of the item is validated, suchas by a user of the originator device 110 or validation device 112 inFIG. 3A, which sets the validated field in the item tracking data blockto TRUE. At 418, the item tracking data block is ciphered and signed tocommit the block to the blockchain and confirm the item transfer. Forexample, the originator using originator device 110 signs item datablock 242B in FIG. 3A to confirm the transfer of the item from theoriginator entity to TransfererA. The blockchain platform then verifiesthe block as described above.

FIG. 4C is a control flow diagram illustrating an example of a process420 for validating provenance of an item being transferred, wherepayment from the transferee to the transferor can be conditioned onsuccessful validation of the item by a third party, such as a certifiedinspector, appraiser or technician. At 422, a transferee, e.g.TransfereeB in FIG. 3A, invokes provenance tracking to validate theprovenance of an item, such as a product, service, or digital content,prior to making payment to the transferor of the item.

In this example, at 424, a check is performed to determine if provenanceverification is required for the transfer. For example, a transfer froman originator, such as a manufacturer or authorized distributor, may notrequire verification of provenance because the item has been in thecustody of the originator. If verification is required, control branchesat 424 to 426 for a third party to verify provenance of the item. Forexample, an inspector confirms the provenance of the item and utilizesvalidation device 112 in FIG. 3A to set the valid field of the itemtracking data block to TRUE. At 428, a Complete method in the itemtracking data block is invoked to transfer payment to the transferor andset the transferee as the holder in the item tracking data block.

FIG. 4D is a control flow diagram illustrating an example of a process430 for transferring a ticket on a ticket tracking data blockchain. At432, if the ticket is not used, e.g. ticket[id].used !=TRUE, atransferee, e.g. TransfereeB in FIG. 3C or 3E, invokes a transfer methoddefined in a ticket tracking data block to transfer the ticket from thetransferor who is the current holder, e.g. ticket[id].holder isTransfereeA, to the subsequent holder, e.g. ticket[id].holder is set toTransfereeB. The transfer process can be repeated for subsequenttransfers, at 434.

At 436, a current holder of the ticket presents the ticket at a venue orservice provider, e.g. TransfereeB using client/server device 120Bpresents the ticket to venue device 114 in FIG. 3B. At 438, a Use methoddefined in the ticket tracking data block is invoked, e.g. by the venuedevice 114, to check that the ticket is not used, e.g.ticket[id].used=FALSE, validate a ticket code and holder as presentedagainst the latest ticket tracking data block 262 in the ticket trackingdata blockchain 260, and, if valid, mark the ticket as used in theticket tracking data block, e.g. ticket[id].used=TRUE.

FIG. 4E is a control flow diagram illustrating another example of aprocess 440 for transferring a ticket on a ticket tracking datablockchain, where a portion of a price increase in the ticket can betransferred to the issuer of the ticket, such as is illustrated in thescenario of FIG. 3E. At 444, if the ticket is not used, a transferee,e.g. TransfereeB in FIG. 3E, invokes a transfer method defined in aticket tracking data block to transfer the ticket from the transferorwho is the current holder, e.g. ticket[id].holder is TransfereeA, to thesubsequent holder, e.g. ticket[id].holder is set to TransfereeB, at atransfer price.

At 446, if the transfer price is greater than the current_price in theticket tracking data block, then control branches to 448, where aportion of the price increase can be sent to the issuer of the ticket.Alternatively, a fixed transfer fee may be sent to the issuer when theticket is transferred. The transfer process can be repeated forsubsequent transfers, at 450. At 452, a current holder of the ticketpresents the ticket at a venue or service provider, e.g. TransfereeBusing client/server device 120B presents the ticket to venue device 114in FIG. 3E. At 454, a Use method defined in the ticket tracking datablock is invoked, e.g. by the venue device 114, to check that the ticketis not used, e.g. ticket[id].used=FALSE, validate a ticket code andholder as presented against the latest ticket tracking data block 262 inthe ticket tracking data blockchain 260, and, if valid, mark the ticketas used in the ticket tracking data block, e.g. ticket[id].used=TRUE.

FIG. 4F is a control flow diagram illustrating still another example ofa process 460 for transferring and using a ticket managed on a tickettracking data blockchain, where an issuer of the ticket creates a tokenon a blockchain for the ticket. In this example, at 462, an issuercreates a token for the ticket on a ticket tracking data blockchain. At464, the token is sent to a purchaser of the ticket by transferringownership of the token to the purchaser on the ticket tracking datablockchain, e.g. by adding a ticket tracking data block with thepurchaser indicated as the owner or holder.

To resell the token, at 466, the current owner or holder use a privatekey to transfer ownership of the token on the ticket tracking datablockchain to a public key address of the new owner. At 468, sale of theticket can be repeated with each current owner using their private keyto transfer the token to the public key address of the new owner on theticket tracking data blockchain. At 469, the current owner or holder ofthe ticket presents their private key and the token to a venue device,which verifies that the ticket is valid and marks it as used.

Access to the provenance data maintained on the item tracking datablockchain or the ticket maintained on the ticket tracking datablockchain may be handled in a variety of ways. For increasedtransparency and availability, the blockchain can be initiated on apublic blockchain with the provenance or ticket data being available toany person who can access the blockchain. Or the item or ticket trackingdata blockchain can be configured to encrypt the provenance or ticketdata and access to the provenance or ticket data controlled, such as myincluding an authorized access list or requiring a key obtained from theoriginator or issuer. For example, access can be limited to entitiesidentified in a list included in the item tracking data blockchain. Inanother example, the originator or issuer distributes a key to entitiesin order to decrypt the provenance or ticket data.

Depending upon the scripting capabilities of the blockchain platform,the data blocks of the item or ticket tracking data blockchain mayinclude more extensive code execution. For example, an item trackingsystem based on an item tracking data blockchain that encrypts theprovenance data and controls access to the provenance may require moreextensive code execution capability in the blockchain than an itemtracking system that makes the provenance data publicly available in anunencrypted state.

It should be appreciated that the utilization of blockchain technology,such as scripting technology within smart contracts, in this contextprovides a high degree of flexibility and variation in the configurationof implementations without departing from the teachings of the presentdisclosure.

Note that the disclosed technology may be applied to tracking andtransferring a variety of types of real and virtual property. Thetechnology may be applied to secure transfer of physical objects,securities, services, or digital content.

FIG. 5 is a data architecture diagram showing an illustrative example ofan interface for accessing an item or ticket tracking data blockchain,such as blockchain 140 in FIG. 1, blockchain 200 in FIG. 2A, blockchain240 in FIG. 2B, blockchain 260 in FIG. 2C, blockchain 240 in FIG. 3A, orblockchain 260 in FIG. 3C. In this example, an evaluation ApplicationProgram Interface (API) 510 provides an interface to the blockchainplatform 520 that supports the item or ticket tracking data blockchain.The blockchain platform 520 supports a smart contract 522, such as itemtracking data block 242 in FIG. 3B or 262 in FIG. 3C, which includesscripts 524 with code that, when executed by the blockchain platform520, performs operations with respect to the item tracking datablockchain.

In the example of FIG. 5, four scripts are defined in smart contract522. The Initialize script 524A provides a capability for an entity toinitialize tracking an item on an item tracking data blockchain, such asproviding for an originator or issuer to establish a genesis block withprovenance information for an item or a unique identifier or key for aticket. The Transfer script 524B provides a capability for transferringthe item or ticket from a transferor or transferee.

The Complete script 524C, or, alternatively, a Use script for a ticket,provides the capability for a transferee to complete transfer of an itemon the blockchain and transfer payment to the transferor. In thisexample, the Complete script calls a Validate script 524D to obtainvalidation of the provenance of the item from a third party, such as avalidation entity. In a ticket context, a Use script can provide acapability for a venue device to verify the authenticity of a ticketupon presentation and mark the ticket as used.

The Transfer script 524D provides the capability for an entity togenerate an item or ticket tracking data block to transfer an item orticket. For example, as discussed above with respect to the itemtracking data blockchain of FIGS. 3A and 3B, the Transfer script can becalled by a transferee to create a new item tracking data block fortransferring an item from a transferor and link the new block to theblockchain. The transferor can confirm the transfer by ciphering andsigning data in the new block.

The scripts 524 shown are merely examples and many other different oradditional scripts can be defined using the capability of the executablescripts in smart contract 522 as provided for on blockchain platform520.

FIG. 5 shows a transferee's client/server system 502 submitting aTransfer request 504 to API 510. API 510 invokes smart contract 522causing blockchain platform 520 to execute the Transfer script 524B togenerate a new item tracking data block on the item tracking datablockchain with the transferee as the new holder of the item. Oncepayment is confirmed by the transferor, the transferor signs the newblock to commit the new block to the blockchain.

Blockchain Ledger Data Structure

FIG. 6A is a data architecture diagram illustrating a simplified exampleof a blockchain ledger 600 based on the blocks 142A-E of the itemtracking data blockchain 140 of FIG. 1. The blockchain ledger 600example of FIG. 6A is simplified to show block headers, metadata andsignatures of blocks 210A-E in order to demonstrate a secure item orticket ledger using a blockchain. In outline, a blockchain ledger may bea globally shared transactional database.

FIG. 6A is an illustrative example of a blockchain ledger 600 with adata tree holding transaction data that is verified using cryptographictechniques. In FIG. 6A, each block 610 includes a block header 612 withinformation regarding previous and subsequent blocks and stores atransaction root node 614 to a data tree 620 holding transactional data.Transaction data may store smart contracts, data related totransactions, or any other data. The elements of smart contracts mayalso be stored within transaction nodes of the blocks.

In the example of FIG. 6A, a Merkle tree 620 is used tocryptographically secure the transaction data. For example, TransactionTx1 node 634A of data tree 620A of block 610A can be hashed to Hash1node 632A, Transaction Tx2 node 638A may be hashed to Hash2 node 636A.Hash1 node 632A and Hash2 node 636A may be hashed to Hash12 node 630A. Asimilar subtree may be formed to generate Hash34 node 640A. Hash12 node630A and Hash34 node 640A may be hashed to Transaction Root 614A hashsorted in the data block 610A. By using a Merkle tree, or any similardata structure, the integrity of the transactions may be checked byverifying the hash is correct.

FIG. 6B is a data architecture diagram showing an illustrative exampleof smart contract code, transactions and messages that are bundled intoa block so that their integrity is cryptographically secure and so thatthey may be appended to a blockchain ledger. In FIG. 6B, smart contracts642 are code that executes on a computer. More specifically, the code ofa smart contract may be stored in a blockchain ledger and executed bynodes of a distributed blockchain platform at a given time. The resultof the smart code execution may be stored in a blockchain ledger.Optionally, a currency may be expended as smart contract code isexecuted. In the example of FIG. 6B, smart contracts 642 are executed ina virtual machine environment, although this is optional.

In FIG. 6B, the aspects of smart contracts 642 are stored in transactiondata nodes in data tree 620 in the blocks 610 of the blockchain ledgerof FIG. 6A. In the example of FIG. 6B, Smart Contract 642A is stored indata block Tx1 node 634A of data tree 620A in block 610A, Smart Contract642B is stored in Tx2 node 638A, Contract Account 654 associated withSmart Contract 642B is stored in Tx3 node 644A, and External Account isstored in Tx4 node 648A.

Storage of Smart Contracts and Transaction Data in the Blockchain Ledger

To ensure the smart contracts are secure and generate secure data, theblockchain ledger must be kept up to date. For example, if a smartcontract is created, the code associated with a smart contract must bestored in a secure way. Similarly, when smart contract code executes andgenerates transaction data, the transaction data must be stored in asecure way.

In the example of FIG. 6B, two possible embodiments for maintenance ofthe blockchain ledger are shown. In one embodiment, untrusted minernodes (“miners”) 680 may be rewarded for solving a cryptographic puzzleand thereby be allowed to append a block to the blockchain.Alternatively, a set of trusted nodes 690 may be used to append the nextblock to the blockchain ledger. Nodes may execute smart contract code,and then one winning node may append the next block to a blockchainledger.

Though aspects of the technology disclosed herein resemble a smartcontract, in the present techniques, the policy of the contract maydetermine the way that the blockchain ledger is maintained. For example,the policy may require that the validation or authorization process forblocks on the ledger is determined by a centralized control of a clusterof trusted nodes. In this case, the centralized control may be a trustednode, such as item originator or ticket issuer device 110, authorized toattest and sign the transaction blocks to validate them and validationby miners may not be needed.

Alternatively, the policy may provide for validation process decided bya decentralized cluster of untrusted nodes. In the situation where theblockchain ledger is distributed to a cluster of untrusted nodes, miningof blocks in the chain may be employed to validate the blockchainledger.

Blockchains may use various time-stamping schemes, such asproof-of-work, to serialize changes. Alternate consensus methods includeproof-of-stake, proof-of-burn, proof-of-research may also be utilized toserialize changes.

As noted above, in some examples, a blockchain ledger may be validatedby miners to secure the blockchain. In this case, miners maycollectively agree on a validation solution to be utilized. However, ifa small network is utilized, e.g. private network, then the solution maybe a Merkle tree and mining for the validation solution may not berequired. When a transaction block is created, e.g. a tracking datablock 142 for item tracking data blockchain 140, the block is anunconfirmed and unidentified entity. To be part of the acknowledged“currency”, it may be added to the blockchain, and therefore relates tothe concept of a trusted cluster.

In a trusted cluster, when a tracking data block 142 is added, everynode competes to acknowledge the next “transaction” (e.g. a transfer ofan item or ticket). In one example, the nodes compete to mine and getthe lowest hash value: min {previous_hash, contents_hash,random_nonce_to_be_guessed}->result. Transaction order is protected bythe computational race (faith that no one entity can beat the collectiveresources of the blockchain network). Mutual authentication parametersare broadcast and acknowledged to prevent double entries in theblockchain.

Alternatively, by broadcasting the meta-data for authenticating a secureledger across a restricted network, e.g. only the signed hash isbroadcast, the blockchain may reduce the risks that come with data beingheld centrally. Decentralized consensus makes blockchains suitable forthe recording of secure transactions or events. The meta-data, which maycontain information related to the data file, may also be ciphered forrestricted access so that the meta-data does not disclose informationpertaining to the data file.

The mining process, such as may be used in concert with the validationprocess 470 of FIG. 4G, may be utilized to deter double accounting,overriding or replaying attacks, with the community arrangement on theagreement based on the “good faith” that no single node can control theentire cluster. A working assumption for mining is the existence ofequivalent power distribution of honest parties with supremacy overdishonest or compromised ones. Every node or miner in a decentralizedsystem has a copy of the blockchain. No centralized “official” copyexists and no user is “trusted” more than any other. Transactions arebroadcast to the network, at 472, using software. Mining nodes compete,at 474, to compute a validation solution to validate transactions, andthen broadcast, at 476, the completed block validation to other nodes.Each node adds the block, at 478, to its copy of the blockchain withtransaction order established by the winning node.

Note that in a restricted network, stake-holders who are authorized tocheck or mine for the data file may or may not access the transactionblocks themselves, but would need to have keys to the meta-data (sincethey are members of the restricted network, and are trusted) to get thedetails. As keys are applied on data with different dataclassifications, the stake-holders can be segmented.

A decentralized blockchain may also use ad-hoc secure message passingand distributed networking. In this example, the item or ticket trackingdata blockchain ledger may be different from a conventional blockchainin that there is a centralized clearing house, e.g. authorized centralcontrol for validation. Without the mining process, the trusted clustercan be contained in a centralized blockchain instead of a public ordemocratic blockchain. One way to view this is that a decentralizedportion is as “democratic N honest parties” (multiparty honest party isa cryptography concept), and a centralized portion as a “trustedmonarchy for blockchain information correction”. For example, there maybe advantages to maintaining the data file as centrally authorized andkept offline.

In some examples, access to a distributed item or ticket tracking datablockchain may be restricted by cryptographic means to be only open toauthorized servers. Since the item or ticket tracking data blockchainledger is distributed, the authorized servers can validate it. A publickey may be used as an address on a public blockchain ledger.

Note that growth of a decentralized blockchain may be accompanied by therisk of node centralization because the computer resources required tooperate on bigger data become increasingly expensive.

The present techniques may involve operations occurring in one or moremachines. As used herein, “machine” means physical data-storage andprocessing hardware programed with instructions to perform specializedcomputing operations. It is to be understood that two or more differentmachines may share hardware components. For example, the same integratedcircuit may be part of two or more different machines.

One of ordinary skill in the art will recognize that a wide variety ofapproaches may be utilized and combined with the present approachinvolving an item tracking data blockchain ledger. The specific examplesof different aspects of an item tracking data blockchain ledgerdescribed herein are illustrative and are not intended to limit thescope of the techniques shown.

Smart Contracts

Smart contracts are defined by code. As described previously, the termsand conditions of the smart contract may be encoded (e.g., by hash) intoa blockchain ledger. Specifically, smart contracts may be compiled intoa bytecode (if executed in a virtual machine), and then the bytecode maybe stored in a blockchain ledger as described previously. Similarly,transaction data executed and generated by smart contracts may be storedin the blockchain ledger in the ways previously described.

Computer Architectures for Use of Smart Contracts and Blockchain Ledgers

Note that at least parts of processes 400, 410, 420, 430, 440, 460 and470 of FIGS. 4A, 4B, 4C, 4D, 4E, 4F and 4G, the scripts of item trackingdata block 242 of FIG. 3B, item tracking data block 262 of FIG. 3D,smart contract 522 of FIG. 5, smart contracts 642 of FIG. 6B, and otherprocesses and operations pertaining to an item tracking data blockchainledger described herein may be implemented in one or more servers, suchas computer environment 800 in FIG. 8, or the cloud, and data definingthe results of user control input signals translated or interpreted asdiscussed herein may be communicated to a user device for display.Alternatively, the item or ticket tracking data blockchain ledgerprocesses may be implemented in a client device. In still otherexamples, some operations may be implemented in one set of computingresources, such as servers, and other steps may be implemented in othercomputing resources, such as a client device.

It should be understood that the methods described herein can be endedat any time and need not be performed in their entireties. Some or alloperations of the methods described herein, and/or substantiallyequivalent operations, can be performed by execution ofcomputer-readable instructions included on a computer-storage media, asdefined below. The term “computer-readable instructions,” and variantsthereof, as used in the description and claims, is used expansivelyherein to include routines, applications, application modules, programmodules, programs, components, data structures, algorithms, and thelike. Computer-readable instructions can be implemented on varioussystem configurations, including single-processor or multiprocessorsystems, minicomputers, mainframe computers, personal computers,hand-held computing devices, microprocessor-based, programmable consumerelectronics, combinations thereof, and the like.

Thus, it should be appreciated that the logical operations describedherein are implemented (1) as a sequence of computer implemented acts orprogram modules running on a computing system and/or (2) asinterconnected machine logic circuits or circuit modules within thecomputing system. The implementation is a matter of choice dependent onthe performance and other requirements of the computing system.Accordingly, the logical operations described herein are referred tovariously as states, operations, structural devices, acts, or modules.These operations, structural devices, acts, and modules may beimplemented in software, in firmware, in special purpose digital logic,and any combination thereof.

As described herein, in conjunction with the FIGURES described herein,the operations of the routines (e.g. processes 400, 410, 420, 430, 440,460 and 470 of FIGS. 4A, 4B, 4C, 4D, 4E, 4F and 4G, the scripts of itemtracking data block 242 of FIG. 3B, item tracking data block 262 of FIG.3D, smart contract 522 of FIG. 5, smart contracts 642 of FIG. 6B) aredescribed herein as being implemented, at least in part, by anapplication, component, and/or circuit. Although the followingillustration refers to the components of FIGS. 1, 3B, 3D, 4A, 4B, 4C,4D, 4E, 4F, 4G, 5 and 6B, it can be appreciated that the operations ofthe routines may be also implemented in many other ways. For example,the routines may be implemented, at least in part, by a computerprocessor or a processor or processors of another computer. In addition,one or more of the operations of the routines may alternatively oradditionally be implemented, at least in part, by a computer workingalone or in conjunction with other software modules.

For example, the operations of routines are described herein as beingimplemented, at least in part, by an application, component and/orcircuit, which are generically referred to herein as modules. In someconfigurations, the modules can be a dynamically linked library (DLL), astatically linked library, functionality produced by an applicationprograming interface (API), a compiled program, an interpreted program,a script or any other executable set of instructions. Data and/ormodules, such as the data and modules disclosed herein, can be stored ina data structure in one or more memory components. Data can be retrievedfrom the data structure by addressing links or references to the datastructure.

Although the following illustration refers to the components of theFIGURES discussed above, it can be appreciated that the operations ofthe routines (e.g. processes 400, 410, 420, 430, 440, 460 and 470 ofFIGS. 4A, 4B, 4C, 4D, 4E, 4F and 4G, the scripts of item tracking datablock 242 of FIG. 3B, item tracking data block 262 of FIG. 3D, smartcontract 522 of FIG. 5, smart contracts 642 of FIG. 6B) may be alsoimplemented in many other ways. For example, the routines may beimplemented, at least in part, by a processor of another remote computeror a local computer or circuit. In addition, one or more of theoperations of the routines may alternatively or additionally beimplemented, at least in part, by a chipset working alone or inconjunction with other software modules. Any service, circuit orapplication suitable for providing the techniques disclosed herein canbe used in operations described herein.

FIG. 7 shows additional details of an example computer architecture 700for a computer, such as the devices 110 and 120A-C (FIG. 1), capable ofexecuting the program components described herein. Thus, the computerarchitecture 700 illustrated in FIG. 7 illustrates an architecture for aserver computer, mobile phone, a PDA, a smart phone, a desktop computer,a netbook computer, a tablet computer, an on-board computer, a gameconsole, and/or a laptop computer. The computer architecture 700 may beutilized to execute any aspects of the software components presentedherein.

The computer architecture 700 illustrated in FIG. 7 includes a centralprocessing unit 702 (“CPU”), a system memory 704, including a randomaccess memory 706 (“RAM”) and a read-only memory (“ROM”) 708, and asystem bus 710 that couples the memory 704 to the CPU 702. A basicinput/output system containing the basic routines that help to transferinformation between sub-elements within the computer architecture 700,such as during startup, is stored in the ROM 708. The computerarchitecture 700 further includes a mass storage device 712 for storingan operating system 707, data (such as a copy of item tracking datablockchain data 720), and one or more application programs.

The mass storage device 712 is connected to the CPU 702 through a massstorage controller (not shown) connected to the bus 710. The massstorage device 712 and its associated computer-readable media providenon-volatile storage for the computer architecture 700. Although thedescription of computer-readable media contained herein refers to a massstorage device, such as a solid-state drive, a hard disk or CD-ROMdrive, it should be appreciated by those skilled in the art thatcomputer-readable media can be any available computer storage media orcommunication media that can be accessed by the computer architecture700.

Communication media includes computer readable instructions, datastructures, program modules, or other data in a modulated data signalsuch as a carrier wave or other transport mechanism and includes anydelivery media. The term “modulated data signal” means a signal that hasone or more of its characteristics changed or set in a manner so as toencode information in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared and other wireless media. Combinations of any of the aboveshould also be included within the scope of computer-readable media.

By way of example, and not limitation, computer storage media mayinclude volatile and non-volatile, removable and non-removable mediaimplemented in any method or technology for storage of information suchas computer-readable instructions, data structures, program modules orother data. For example, computer media includes, but is not limited to,RAM, ROM, EPROM, EEPROM, flash memory or other solid state memorytechnology, CD-ROM, digital versatile disks (“DVD”), HD-DVD, BLU-RAY, orother optical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other medium which canbe used to store the desired information and which can be accessed bythe computer architecture 700. For purposes the claims, the phrase“computer storage medium,” “computer-readable storage medium” andvariations thereof, does not include waves, signals, and/or othertransitory and/or intangible communication media, per se.

According to various configurations, the computer architecture 700 mayoperate in a networked environment using logical connections to remotecomputers through the network 756 and/or another network (not shown).The computer architecture 700 may connect to the network 756 through anetwork interface unit 714 connected to the bus 710. It should beappreciated that the network interface unit 714 also may be utilized toconnect to other types of networks and remote computer systems. Thecomputer architecture 700 also may include an input/output controller716 for receiving and processing input from a number of other devices,including a keyboard, mouse, game controller, television remote orelectronic stylus (not shown in FIG. 7). Similarly, the input/outputcontroller 716 may provide output to a display screen, a printer, orother type of output device (also not shown in FIG. 7).

It should be appreciated that the software components described hereinmay, when loaded into the CPU 702 and executed, transform the CPU 702and the overall computer architecture 700 from a general-purposecomputing system into a special-purpose computing system customized tofacilitate the functionality presented herein. The CPU 702 may beconstructed from any number of transistors or other discrete circuitelements, which may individually or collectively assume any number ofstates. More specifically, the CPU 702 may operate as a finite-statemachine, in response to executable instructions contained within thesoftware modules disclosed herein. These computer-executableinstructions may transform the CPU 702 by specifying how the CPU 702transitions between states, thereby transforming the transistors orother discrete hardware elements constituting the CPU 702.

Encoding the software modules presented herein also may transform thephysical structure of the computer-readable media presented herein. Thespecific transformation of physical structure may depend on variousfactors, in different implementations of this description. Examples ofsuch factors may include, but are not limited to, the technology used toimplement the computer-readable media, whether the computer-readablemedia is characterized as primary or secondary storage, and the like.For example, if the computer-readable media is implemented assemiconductor-based memory, the software disclosed herein may be encodedon the computer-readable media by transforming the physical state of thesemiconductor memory. For example, the software may transform the stateof transistors, capacitors, or other discrete circuit elementsconstituting the semiconductor memory. The software also may transformthe physical state of such components in order to store data thereupon.

As another example, the computer-readable media disclosed herein may beimplemented using magnetic or optical technology. In suchimplementations, the software presented herein may transform thephysical state of magnetic or optical media, when the software isencoded therein. These transformations may include altering the magneticcharacteristics of particular locations within given magnetic media.These transformations also may include altering the physical features orcharacteristics of particular locations within given optical media, tochange the optical characteristics of those locations. Othertransformations of physical media are possible without departing fromthe scope and spirit of the present description, with the foregoingexamples provided only to facilitate this discussion.

In light of the above, it should be appreciated that many types ofphysical transformations take place in the computer architecture 700 inorder to store and execute the software components presented herein. Italso should be appreciated that the computer architecture 700 mayinclude other types of computing devices, including hand-held computers,embedded computer systems, personal digital assistants, and other typesof computing devices known to those skilled in the art. It is alsocontemplated that the computer architecture 700 may not include all ofthe components shown in FIG. 7, may include other components that arenot explicitly shown in FIG. 7, or may utilize an architecturecompletely different than that shown in FIG. 7.

FIG. 8 depicts an illustrative distributed computing environment 800capable of executing the software components described herein for anitem tracking data blockchain ledger. Thus, the distributed computingenvironment 800 illustrated in FIG. 8 can be utilized to execute manyaspects of the software components presented herein. For example, thedistributed computing environment 800 can be utilized to execute one ormore aspects of the software components described herein. Also, thedistributed computing environment 800 may represent components of thedistributed blockchain platform discussed above.

According to various implementations, the distributed computingenvironment 800 includes a computing environment 802 operating on, incommunication with, or as part of the network 804. The network 804 maybe or may include the network 556, described above. The network 804 alsocan include various access networks. One or more client devices806A-806N (hereinafter referred to collectively and/or generically as“clients 806”) can communicate with the computing environment 802 viathe network 804 and/or other connections (not illustrated in FIG. 8). Inone illustrated configuration, the clients 806 include a computingdevice 806A, such as a laptop computer, a desktop computer, or othercomputing device; a slate or tablet computing device (“tablet computingdevice”) 806B; a mobile computing device 806C such as a mobiletelephone, a smart phone, an on-board computer, or other mobilecomputing device; a server computer 806D; and/or other devices 806N,which can include a hardware security module. It should be understoodthat any number of devices 806 can communicate with the computingenvironment 802. Two example computing architectures for the devices 806are illustrated and described herein with reference to FIGS. 7 and 8. Itshould be understood that the illustrated devices 806 and computingarchitectures illustrated and described herein are illustrative only andshould not be construed as being limited in any way.

In the illustrated configuration, the computing environment 802 includesapplication servers 808, data storage 810, and one or more networkinterfaces 812. According to various implementations, the functionalityof the application servers 808 can be provided by one or more servercomputers that are executing as part of, or in communication with, thenetwork 804. The application servers 808 can host various services,virtual machines, portals, and/or other resources. In the illustratedconfiguration, the application servers 808 host one or more virtualmachines 814 for hosting applications or other functionality. Accordingto various implementations, the virtual machines 814 host one or moreapplications and/or software modules for a data management blockchainledger. It should be understood that this configuration is illustrativeonly and should not be construed as being limiting in any way.

According to various implementations, the application servers 808 alsoinclude one or more data file management services 820 and one or moreblockchain services 822. The data file management services 820 caninclude services for managing a data file on an item tracking datablockchain, such as item tracking data blockchain 140 in FIG. 1. Theblockchain services 822 can include services for participating inmanagement of one or more blockchains, such as by creating genesisblocks, tracking data blocks, and performing validation.

As shown in FIG. 8, the application servers 808 also can host otherservices, applications, portals, and/or other resources (“otherresources”) 824. The other resources 824 can include, but are notlimited to, data encryption, data sharing, or any other functionality.

As mentioned above, the computing environment 802 can include datastorage 810. According to various implementations, the functionality ofthe data storage 810 is provided by one or more databases or data storesoperating on, or in communication with, the network 804. Thefunctionality of the data storage 810 also can be provided by one ormore server computers configured to host data for the computingenvironment 802. The data storage 810 can include, host, or provide oneor more real or virtual data stores 826A-826N (hereinafter referred tocollectively and/or generically as “datastores 826”). The datastores 826are configured to host data used or created by the application servers808 and/or other data. Aspects of the datastores 826 may be associatedwith services for an item tracking data blockchain. Although notillustrated in FIG. 8, the datastores 826 also can host or store webpage documents, word documents, presentation documents, data structures,algorithms for execution by a recommendation engine, and/or other datautilized by any application program or another module.

The computing environment 802 can communicate with, or be accessed by,the network interfaces 812. The network interfaces 812 can includevarious types of network hardware and software for supportingcommunications between two or more computing devices including, but notlimited to, the clients 806 and the application servers 808. It shouldbe appreciated that the network interfaces 812 also may be utilized toconnect to other types of networks and/or computer systems.

It should be understood that the distributed computing environment 800described herein can provide any aspects of the software elementsdescribed herein with any number of virtual computing resources and/orother distributed computing functionality that can be configured toexecute any aspects of the software components disclosed herein.According to various implementations of the concepts and technologiesdisclosed herein, the distributed computing environment 800 may providethe software functionality described herein as a service to the clientsusing devices 806. It should be understood that the devices 806 caninclude real or virtual machines including, but not limited to, servercomputers, web servers, personal computers, mobile computing devices,smart phones, and/or other devices, which can include user inputdevices. As such, various configurations of the concepts andtechnologies disclosed herein enable any device configured to access thedistributed computing environment 800 to utilize the functionalitydescribed herein for creating and supporting an item tracking datablockchain ledger, among other aspects.

Turning now to FIG. 9, an illustrative computing device architecture 900for a computing device that is capable of executing various softwarecomponents is described herein for an item tracking data blockchainledger. The computing device architecture 900 is applicable to computingdevices that can manage an item tracking data blockchain ledger. In someconfigurations, the computing devices include, but are not limited to,mobile telephones, on-board computers, tablet devices, slate devices,portable video game devices, traditional desktop computers, portablecomputers (e.g., laptops, notebooks, ultra-portables, and netbooks),server computers, game consoles, and other computer systems. Thecomputing device architecture 900 is applicable to the item originatoror ticket issuer device 110, validation device 112, venue device 114,and client/servers 120A-C shown in FIG. 1 and computing device 806A-Nshown in FIG. 8.

The computing device architecture 900 illustrated in FIG. 9 includes aprocessor 902, memory components 904, network connectivity components906, sensor components 908, input/output components 910, and powercomponents 912. In the illustrated configuration, the processor 902 isin communication with the memory components 904, the networkconnectivity components 906, the sensor components 908, the input/output(“I/O”) components 910, and the power components 912. Although noconnections are shown between the individual components illustrated inFIG. 9, the components can interact to carry out device functions. Insome configurations, the components are arranged so as to communicatevia one or more busses (not shown).

The processor 902 includes a central processing unit (“CPU”) configuredto process data, execute computer-executable instructions of one or moreapplication programs, and communicate with other components of thecomputing device architecture 900 in order to perform variousfunctionality described herein. The processor 902 may be utilized toexecute aspects of the software components presented herein and,particularly, those that utilize, at least in part, secure data.

In some configurations, the processor 902 includes a graphics processingunit (“GPU”) configured to accelerate operations performed by the CPU,including, but not limited to, operations performed by executing securecomputing applications, general-purpose scientific and/or engineeringcomputing applications, as well as graphics-intensive computingapplications such as high resolution video (e.g., 620P, 1080P, andhigher resolution), video games, three-dimensional (“3D”) modelingapplications, and the like. In some configurations, the processor 902 isconfigured to communicate with a discrete GPU (not shown). In any case,the CPU and GPU may be configured in accordance with a co-processingCPU/GPU computing model, wherein a sequential part of an applicationexecutes on the CPU and a computationally-intensive part is acceleratedby the GPU.

In some configurations, the processor 902 is, or is included in, asystem-on-chip (“SoC”) along with one or more of the other componentsdescribed herein below. For example, the SoC may include the processor902, a GPU, one or more of the network connectivity components 906, andone or more of the sensor components 908. In some configurations, theprocessor 902 is fabricated, in part, utilizing a package-on-package(“PoP”) integrated circuit packaging technique. The processor 902 may bea single core or multi-core processor.

The processor 902 may be created in accordance with an ARM architecture,available for license from ARM HOLDINGS of Cambridge, United Kingdom.Alternatively, the processor 902 may be created in accordance with anx86 architecture, such as is available from INTEL CORPORATION ofMountain View, Calif. and others. In some configurations, the processor902 is a SNAPDRAGON SoC, available from QUALCOMM of San Diego, Calif., aTEGRA SoC, available from NVIDIA of Santa Clara, Calif., a HUMMINGBIRDSoC, available from SAMSUNG of Seoul, South Korea, an Open MultimediaApplication Platform (“OMAP”) SoC, available from TEXAS INSTRUMENTS ofDallas, Tex., a customized version of any of the above SoCs, or aproprietary SoC.

The memory components 904 include a random access memory (“RAM”) 914, aread-only memory (“ROM”) 916, an integrated storage memory (“integratedstorage”) 918, and a removable storage memory (“removable storage”) 920.In some configurations, the RAM 914 or a portion thereof, the ROM 916 ora portion thereof, and/or some combination of the RAM 914 and the ROM916 is integrated in the processor 902. In some configurations, the ROM916 is configured to store a firmware, an operating system or a portionthereof (e.g., operating system kernel), and/or a bootloader to load anoperating system kernel from the integrated storage 918 and/or theremovable storage 920.

The integrated storage 918 can include a solid-state memory, a harddisk, or a combination of solid-state memory and a hard disk. Theintegrated storage 918 may be soldered or otherwise connected to a logicboard upon which the processor 902 and other components described hereinalso may be connected. As such, the integrated storage 918 is integratedin the computing device. The integrated storage 918 is configured tostore an operating system or portions thereof, application programs,data, and other software components described herein.

The removable storage 920 can include a solid-state memory, a hard disk,or a combination of solid-state memory and a hard disk. In someconfigurations, the removable storage 920 is provided in lieu of theintegrated storage 918. In other configurations, the removable storage920 is provided as additional optional storage. In some configurations,the removable storage 920 is logically combined with the integratedstorage 918 such that the total available storage is made available as atotal combined storage capacity. In some configurations, the totalcombined capacity of the integrated storage 918 and the removablestorage 920 is shown to a user instead of separate storage capacitiesfor the integrated storage 918 and the removable storage 920.

The removable storage 920 is configured to be inserted into a removablestorage memory slot (not shown) or other mechanism by which theremovable storage 920 is inserted and secured to facilitate a connectionover which the removable storage 920 can communicate with othercomponents of the computing device, such as the processor 902. Theremovable storage 920 may be embodied in various memory card formatsincluding, but not limited to, PC card, CompactFlash card, memory stick,secure digital (“SD”), miniSD, microSD, universal integrated circuitcard (“UICC”) (e.g., a subscriber identity module (“SIM”) or universalSIM (“USIM”)), a proprietary format, or the like.

It can be understood that one or more of the memory components 904 canstore an operating system. According to various configurations, theoperating system may include, but is not limited to, server operatingsystems such as various forms of UNIX certified by The Open Group andLINUX certified by the Free Software Foundation, or aspects ofSoftware-as-a-Service (SaaS) architectures, such as MICROSFT AZURE fromMicrosoft Corporation of Redmond, Wash. or AWS from Amazon Corporationof Seattle, Wash. The operating system may also include WINDOWS MOBILEOS from Microsoft Corporation of Redmond, Wash., WINDOWS PHONE OS fromMicrosoft Corporation, WINDOWS from Microsoft Corporation, PALM WEB OSfrom Hewlett-Packard Company of Palo Alto, Calif., BLACKBERRY OS fromResearch In Motion Limited of Waterloo, Ontario, Canada, MAC OS or IOSfrom Apple Inc. of Cupertino, Calif., and ANDROID OS from Google Inc. ofMountain View, Calif. Other operating systems are contemplated.

The network connectivity components 906 include a wireless wide areanetwork component (“WWAN component”) 922, a wireless local area networkcomponent (“WLAN component”) 924, and a wireless personal area networkcomponent (“WPAN component”) 926. The network connectivity components906 facilitate communications to and from the network 956 or anothernetwork, which may be a WWAN, a WLAN, or a WPAN. Although only thenetwork 956 is illustrated, the network connectivity components 906 mayfacilitate simultaneous communication with multiple networks, includingthe network 956 of FIG. 9. For example, the network connectivitycomponents 906 may facilitate simultaneous communications with multiplenetworks via one or more of a WWAN, a WLAN, or a WPAN.

The network 956 may be or may include a WWAN, such as a mobiletelecommunications network utilizing one or more mobiletelecommunications technologies to provide voice and/or data services toa computing device utilizing the computing device architecture 900 viathe WWAN component 922. The mobile telecommunications technologies caninclude, but are not limited to, Global System for Mobile communications(“GSM”), Code Division Multiple Access (“CDMA”) ONE, CDMA7000, UniversalMobile Telecommunications System (“UMTS”), Long Term Evolution (“LTE”),and Worldwide Interoperability for Microwave Access (“WiMAX”). Moreover,the network 956 may utilize various channel access methods (which may ormay not be used by the aforementioned standards) including, but notlimited to, Time Division Multiple Access (“TDMA”), Frequency DivisionMultiple Access (“FDMA”), CDMA, wideband CDMA (“W-CDMA”), OrthogonalFrequency Division Multiplexing (“OFDM”), Space Division Multiple Access(“SDMA”), and the like. Data communications may be provided usingGeneral Packet Radio Service (“GPRS”), Enhanced Data rates for GlobalEvolution (“EDGE”), the High-Speed Packet Access (“HSPA”) protocolfamily including High-Speed Downlink Packet Access (“HSDPA”), EnhancedUplink (“EUL”) or otherwise termed High-Speed Uplink Packet Access(“HSUPA”), Evolved HSPA (“HSPA+”), LTE, and various other current andfuture wireless data access standards. The network 956 may be configuredto provide voice and/or data communications with any combination of theabove technologies. The network 956 may be configured to or be adaptedto provide voice and/or data communications in accordance with futuregeneration technologies.

In some configurations, the WWAN component 922 is configured to providedual-multi-mode connectivity to the network 956. For example, the WWANcomponent 922 may be configured to provide connectivity to the network956, wherein the network 956 provides service via GSM and UMTStechnologies, or via some other combination of technologies.Alternatively, multiple WWAN components 922 may be utilized to performsuch functionality, and/or provide additional functionality to supportother non-compatible technologies (i.e., incapable of being supported bya single WWAN component). The WWAN component 922 may facilitate similarconnectivity to multiple networks (e.g., a UMTS network and an LTEnetwork).

The network 956 may be a WLAN operating in accordance with one or moreInstitute of Electrical and Electronic Engineers (“IEEE”) 802.11standards, such as IEEE 802.11a, 802.11b, 802.11g, 802.11n, and/orfuture 802.11 standard (referred to herein collectively as WI-FI). Draft802.11 standards are also contemplated. In some configurations, the WLANis implemented utilizing one or more wireless WI-FI access points. Insome configurations, one or more of the wireless WI-FI access points areanother computing device with connectivity to a WWAN that arefunctioning as a WI-FI hotspot. The WLAN component 924 is configured toconnect to the network 956 via the WI-FI access points. Such connectionsmay be secured via various encryption technologies including, but notlimited to, WI-FI Protected Access (“WPA”), WPA2, Wired EquivalentPrivacy (“WEP”), and the like.

The network 956 may be a WPAN operating in accordance with Infrared DataAssociation (“IrDA”), BLUETOOTH, wireless Universal Serial Bus (“USB”),Z-Wave, ZIGBEE, or some other short-range wireless technology. In someconfigurations, the WPAN component 926 is configured to facilitatecommunications with other devices, such as peripherals, computers, orother computing devices via the WPAN.

The sensor components 908 include a magnetometer 928, an ambient lightsensor 930, a proximity sensor 932, an accelerometer 934, a gyroscope936, and a Global Positioning System sensor (“GPS sensor”) 938. It iscontemplated that other sensors, such as, but not limited to,temperature sensors or shock detection sensors, also may be incorporatedin the computing device architecture 900.

The I/O components 910 include a display 940, a touchscreen 942, a dataI/O interface component (“data I/O”) 944, an audio I/O interfacecomponent (“audio I/O”) 946, a video I/O interface component (“videoI/O”) 948, and a camera 950. In some configurations, the display 940 andthe touchscreen 942 are combined. In some configurations two or more ofthe data I/O component 944, the audio I/O component 946, and the videoI/O component 948 are combined. The I/O components 910 may includediscrete processors configured to support the various interfacesdescribed below or may include processing functionality built-in to theprocessor 902.

The illustrated power components 912 include one or more batteries 952,which can be connected to a battery gauge 954. The batteries 952 may berechargeable or disposable. Rechargeable battery types include, but arenot limited to, lithium polymer, lithium ion, nickel cadmium, and nickelmetal hydride. Each of the batteries 952 may be made of one or morecells.

The power components 912 may also include a power connector, which maybe combined with one or more of the aforementioned I/O components 910.The power components 912 may interface with an external power system orcharging equipment via an I/O component.

Examples of Various Implementations

In closing, although the various configurations have been described inlanguage specific to structural features and/or methodological acts, itis to be understood that the subject matter defined in the appendedrepresentations is not necessarily limited to the specific features oracts described. Rather, the specific features and acts are disclosed asexample forms of implementing the claimed subject matter.

Although the subject matter presented herein has been described inlanguage specific to computer structural features, methodological andtransformative acts, specific computing machinery, and computer readablemedia, it is to be understood that the subject matter set forth in theappended claims is not necessarily limited to the specific features,acts, or media described herein. Rather, the specific features, acts andmediums are disclosed as example forms of implementing the claimedsubject matter.

The subject matter described above is provided by way of illustrationonly and should not be construed as limiting. Various modifications andchanges can be made to the subject matter described herein withoutfollowing the example configurations and applications illustrated anddescribed, and without departing from the scope of the presentdisclosure, which is set forth in the following claims.

The present disclosure is made in light of the following clauses:

Clause 1: A computer-implemented item provenance tracking method, themethod comprising: generating, by an originator entity, a first itemtracking data block on an item tracking data blockchain, the first itemtracking data block storing data identifying an item, a holderidentifier for identifying a holder of the item and a validatedindicator, where holder identifier is set to an identifier of theoriginator entity for the item and the validated indicator is set to atrue state; signing data in the first item tracking data block with afirst cryptographic digital signature of the originator entity;generating, by a first transferee entity, a second item tracking datablock on the item tracking data blockchain, the second item trackingdata block storing a holder identifier and a validated indicator, wherethe holder identifier is set to an identifier of the first transfereeentity and the validated indicator is set to the true state; linking thesecond item tracking data block to the first item tracking data block;and signing data in the second item tracking data block with a secondcryptographic digital signature of the originator entity.

Clause 2: The computer-implemented method of Clause 1, where the methodincludes: generating, by a second transferee entity, a third itemtracking data block on the item tracking data blockchain, the third itemtracking data block storing a holder identifier and a validatedindicator, where the holder identifier is set to an identifier of thesecond transferee entity and the validated indicator is set to the falsestate; linking the third item tracking data block to the second itemtracking data block; responsive to receiving a verification message froma third party, setting the validated indicator in the third itemtracking block to true; and signing data in the third item tracking datablock with a cryptographic digital signature of the first transfereeentity.

Clause 3: The computer-implemented method of Clause 2, where: theidentifier of the originator entity comprises a public key address forthe originator entity; the identifier of the first transferee entitycomprises a public key address for the first transferee entity; theidentifier of the second transferee entity comprises a public keyaddress for the second transferee entity: the first cryptographicdigital signature of the originator entity is partially based on datawithin the first item tracking data block; the second cryptographicdigital signature of the originator entity is partially based on datawithin the second item tracking data block; and the cryptographicdigital signature of the first transferee entity is partially based ondata within the third item tracking data block.

Clause 4: The computer-implemented method of Clause 2, where the step ofresponsive to receiving a verification message from a validation party,setting the validated indicator in the third item tracking block to trueincludes, responsive to receiving the verification message from thevalidation party, transferring payment for the item to the firsttransferee.

Clause 5: The computer-implemented method of Clause 2, where thevalidation party comprises one of the originator entity, an entityauthorized by the originator entity, and a certified entity.

Clause 6: The computer-implemented method of Clause 2, where: the itemfurther comprises a ticket; and the step of generating, by an originatorentity, a first item tracking data block on an item tracking datablockchain includes: generating a unique code value for the ticket,storing the unique code value for the ticket in the first item trackingdata block, and storing a used indicator in the first item tracking datablock, where the used indicator is set to the false state.

Clause 7: The computer-implemented method of Clause 4, the methodfurther comprising: receiving from the second transferee entity apresented code value; and if the used indicator stored in the thirdticket tracking data block is set to the false state and the presentedcode value corresponds to the unique code value stored in the thirdticket tracking data block, indicating the ticket as valid and settingthe used indicator to the true state.

8. A computer-implemented ticket tracking method, the method comprising:

generating, by an issuer entity, a first ticket tracking data block on aticket tracking data blockchain, the first ticket tracking data blockstoring a unique code value for the ticket, a holder identifier foridentifying a holder of the ticket and a used indicator, where holderidentifier is set to an identifier of the issuer entity for the ticketand the used indicator is set to a false state;

signing data in the first ticket tracking data block with a firstcryptographic digital signature of the issuer entity;

generating, by a first transferee entity, a second ticket tracking datablock on the ticket tracking data blockchain, the second ticket trackingdata block storing a holder identifier, the unique code value for theticket, and a used indicator, where the holder identifier is set to anidentifier of the first transferee entity and the used indicator is setto the false state;

linking the second ticket tracking data block to the first tickettracking data block; and

signing data in the second ticket tracking data block with a secondcryptographic digital signature of the issuer entity.

Clause 9: The computer-implemented method of Clause 8, where the methodincludes: if the used indicator is set to the false state, generating,by a second transferee entity, a third ticket tracking data block on theticket tracking data blockchain, the third ticket tracking data blockstoring a holder identifier, the unique code value for the ticket, and aused indicator, where the holder identifier is set to an identifier ofthe second transferee entity and the used indicator is set to the falsestate; linking the third ticket tracking data block to the second tickettracking data block; and signing data in the third ticket tracking datablock with a cryptographic digital signature of the first transfereeentity.

Clause 10. The computer-implemented method of Clause 9, the methodfurther comprising: receiving from the second transferee entity apresented code value; and if the used indicator stored in the thirdticket tracking data block is set to the false state and the presentedcode value corresponds to the unique code value stored in the thirdticket tracking data block, indicating the ticket as valid and settingthe used indicator to the true state.

Clause 11. The computer-implemented method of Clause 9, where:

the second ticket tracking data block stores a price value and the pricevalue is set to a first transfer price for the transfer from the issuerentity to the first transferee entity; and the step of generating, by asecond transferee entity, a third ticket tracking data block on theticket tracking data blockchain includes determining whether a secondtransfer price for the transfer from the first transferee entity to thesecond transferee entity is greater than the first transfer price, andif the second transfer price is greater than the first transfer price,send a payment from the first transferee to the issuer entity.

Clause 12. The computer-implemented method of Clause 11, where an amountof the payment from the first transferee to the issuer entity comprisesat least one of a predetermined amount, an amount based on the secondtransfer price, and an amount based on a difference between the firstand second transfer prices.

Clause 13. The computer-implemented method of Clause 9, where:

the identifier of the issuer entity comprises a public key address forthe issuer entity; the identifier of the first transferee entitycomprises a public key address for the first transferee entity; theidentifier of the second transferee entity comprises a public keyaddress for the second transferee entity: the first cryptographicdigital signature of the issuer entity is partially based on data withinthe first ticket tracking data block; the second cryptographic digitalsignature of the issuer entity is partially based on data within thesecond ticket tracking data block; and the cryptographic digitalsignature of the first transferee entity is partially based on datawithin the third ticket tracking data block.

Clause 14. The computer-implemented method of Clause 9, where: the stepof signing data in the second ticket tracking data block with a secondcryptographic digital signature of the issuer entity is performed inresponse to confirmation of payment from the first transferee entity tothe issuer entity; and the step of signing data in the third tickettracking data block with a cryptographic digital signature of the firsttransferee entity is performed in response to confirmation of paymentfrom the second transferee entity to the first transferee entity.

Clause 15. A system for tracking a ticket on a ticket tracking datablockchain, where the ticket tracking data blockchain stores a uniquecode value for the ticket, a holder identifier for identifying a holderof the ticket and a used indicator indicating whether the ticket hasbeen used, the system comprising: one or more processors; and one ormore memory devices in communication with the one or more processors,the memory devices having computer-readable instructions storedthereupon that, when executed by the processors, cause the processorsto: responsive to a first transfer request, if the used indicatorindicates that the ticket has not been used, generate, by a firsttransferee entity, a first ticket tracking data block on a tickettracking data blockchain, the first ticket tracking data block storingan identifier of the first transferee entity in a holder identifier ofthe first ticket tracking data block; link the first ticket trackingdata block to a previous ticket tracking data block on the tickettracking data blockchain; and sign data in the first ticket trackingdata block with a cryptographic digital signature of a transferor entityidentified in the holder identifier stored in the previous tickettracking data block.

Clause 16. The system of Clause 15, where the memory device includescomputer-readable instructions stored thereupon that, when executed bythe processors, cause the processors to: responsive to a second transferrequest, if the used indicator indicates that the ticket has not beenused, generate, by a second transferee entity, a second ticket trackingdata block on the ticket tracking data blockchain, the second identifierticket tracking data block storing an identifier of the secondtransferee entity in the holder identifier; link the second tickettracking data block to a first ticket tracking data block on the tickettracking data blockchain; and sign data in the second ticket trackingdata block with a cryptographic digital signature of the firsttransferee entity identified in the holder identifier stored in thefirst ticket tracking data block.

Clause 17. The system of Clause 16, where the memory device includescomputer-readable instructions stored thereupon that, when executed bythe processors, cause the processors to: receive a presented holderidentifier and a presented code value; and if the used indicatorindicates that the ticket has not been used, the presented holderidentifier corresponds to the holder identifier in the a most recentticket tracking data block in the ticket tracking data blockchain, andthe presented code value corresponds to the unique code value stored inthe ticket tracking data blockchain, indicate the ticket as valid andset the used indicator in the ticket tracking data blockchain toindicate that the ticket has been used.

Clause 18. The system of Clause 16, where the first ticket tracking datablock stores a first transfer price value corresponding to the firsttransfer and the memory device includes computer-readable instructionsstored thereupon that, when executed by the processors, cause theprocessors to: in the step of generating, by a second transferee entity,a second ticket tracking data block on the ticket tracking datablockchain, determine whether a second transfer price value for thetransfer from the first transferee entity to the second transfereeentity is greater than the first transfer price value, and if the secondtransfer price value is greater than the first transfer price value,send a payment from the first transferee to an issuer entity.

Clause 19. The system of Clause 18, where an amount of the payment fromthe first transferee to the issuer entity comprises at least one of apredetermined amount, an amount based on the second transfer price, andan amount based on a difference between the first and second transferprices.

Clause 20. The system of Clause 16, where the memory device includescomputer-readable instructions stored thereupon that, when executed bythe processors, cause the processors to: perform the operation to signdata in the first ticket tracking data block with a cryptographicdigital signature of a transferor entity identified in the holderidentifier stored in the previous ticket tracking data block in responseto confirmation of payment from the first transferee entity to thetransferor entity; and perform the operation to sign data in the secondticket tracking data block with a cryptographic digital signature of thefirst transferee entity identified in the holder identifier stored inthe first ticket tracking data block in response to confirmation ofpayment from the second transferee entity to the first transfereeentity.

The invention claimed is:
 1. A computer-implemented ticket tracking method, the method comprising: generating, by an issuer entity, a first ticket tracking data block on a ticket tracking data blockchain, the first ticket tracking data block storing a unique code value for the ticket, a holder identifier for identifying a holder of the ticket and a used indicator, where holder identifier is set to an identifier of the issuer entity for the ticket and the used indicator is set to a false state; signing data in the first ticket tracking data block with a first cryptographic digital signature of the issuer entity; generating, by a first transferee entity, a second ticket tracking data block on the ticket tracking data blockchain, the second ticket tracking data block storing a holder identifier, the unique code value for the ticket, and a used indicator, where the holder identifier is set to an identifier of the first transferee entity and the used indicator is set to the false state; linking the second ticket tracking data block to the first ticket tracking data block; and signing data in the second ticket tracking data block with a second cryptographic digital signature of the issuer entity.
 2. The computer-implemented method of claim 1, the method further comprising: if the used indicator is set to the false state, generating, by a second transferee entity, a third ticket tracking data block on the ticket tracking data blockchain, the third ticket tracking data block storing a holder identifier, the unique code value for the ticket, and a used indicator, where the holder identifier is set to an identifier of the second transferee entity and the used indicator is set to the false state; linking the third ticket tracking data block to the second ticket tracking data block; and signing data in the third ticket tracking data block with a cryptographic digital signature of the first transferee entity.
 3. The computer-implemented method of claim 2, the method further comprising: receiving from the second transferee entity a presented code value; and if the used indicator stored in the third ticket tracking data block is set to the false state and the presented code value corresponds to the unique code value stored in the third ticket tracking data block, indicating the ticket as valid and setting the used indicator to the true state.
 4. The computer-implemented method of claim 2, where: the second ticket tracking data block stores a price value and the price value is set to a first transfer price for the transfer from the issuer entity to the first transferee entity; and the generating, by the second transferee entity, the third ticket tracking data block on the ticket tracking data blockchain includes determining whether a second transfer price for the transfer from the first transferee entity to the second transferee entity is greater than the first transfer price, and if the second transfer price is greater than the first transfer price, send a payment from the first transferee to the issuer entity.
 5. The computer-implemented method of claim 4, where an amount of the payment from the first transferee to the issuer entity comprises at least one of a predetermined amount, an amount based on the second transfer price, and an amount based on a difference between the first and second transfer prices.
 6. The computer-implemented method of claim 2, where: the identifier of the issuer entity comprises a public key address for the issuer entity; the identifier of the first transferee entity comprises a public key address for the first transferee entity; the identifier of the second transferee entity comprises a public key address for the second transferee entity; the first cryptographic digital signature of the issuer entity is partially based on data within the first ticket tracking data block; the second cryptographic digital signature of the issuer entity is partially based on data within the second ticket tracking data block; and the cryptographic digital signature of the first transferee entity is partially based on data within the third ticket tracking data block.
 7. The computer-implemented method of claim 2, where: the signing the data in the second ticket tracking data block with the second cryptographic digital signature of the issuer entity is performed in response to confirmation of payment from the first transferee entity to the issuer entity; and the signing the data in the third ticket tracking data block with the cryptographic digital signature of the first transferee entity is performed in response to confirmation of payment from the second transferee entity to the first transferee entity.
 8. A system for tracking a ticket on a ticket tracking data blockchain, where the ticket tracking data blockchain stores a unique code value for the ticket, a holder identifier for identifying a holder of the ticket and a used indicator indicating whether the ticket has been used, the system comprising: one or more processors; and one or more memory devices in communication with the one or more processors, the memory devices having computer-readable instructions stored thereupon that, when executed by the processors, cause the processors to: responsive to a first transfer request, if the used indicator indicates that the ticket has not been used, generate, by a first transferee entity, a first ticket tracking data block on a ticket tracking data blockchain, the first ticket tracking data block storing an identifier of the first transferee entity in a holder identifier of the first ticket tracking data block; link the first ticket tracking data block to a previous ticket tracking data block on the ticket tracking data blockchain; and sign data in the first ticket tracking data block with a cryptographic digital signature of a transferor entity identified in the holder identifier stored in the previous ticket tracking data block.
 9. The system of claim 8, where the computer-readable instructions further cause the processors to: responsive to a second transfer request, if the used indicator indicates that the ticket has not been used, generate, by a second transferee entity, a second ticket tracking data block on the ticket tracking data blockchain, the second identifier ticket tracking data block storing an identifier of the second transferee entity in the holder identifier; link the second ticket tracking data block to a first ticket tracking data block on the ticket tracking data blockchain; and sign data in the second ticket tracking data block with a cryptographic digital signature of the first transferee entity identified in the holder identifier stored in the first ticket tracking data block.
 10. The system of claim 9, where the computer-readable instructions further cause the processors to: receive a presented holder identifier and a presented code value; and if the used indicator indicates that the ticket has not been used, the presented holder identifier corresponds to the holder identifier in the a most recent ticket tracking data block in the ticket tracking data blockchain, and the presented code value corresponds to the unique code value stored in the ticket tracking data blockchain, indicate the ticket as valid and set the used indicator in the ticket tracking data blockchain to indicate that the ticket has been used.
 11. The system of claim 9, where: the first ticket tracking data block stores a first transfer price value corresponding to the first transfer; and the computer-readable instructions further cause the processors to: determine whether a second transfer price value for the transfer from the first transferee entity to the second transferee entity is greater than the first transfer price value, and if the second transfer price value is greater than the first transfer price value, sending a payment from the first transferee to an issuer entity.
 12. The system of claim 11, where an amount of the payment from the first transferee to the issuer entity comprises at least one selected from the following: a predetermined amount, an amount based on the second transfer price, and an amount based on a difference between the first and second transfer prices.
 13. The system of claim 9, where the computer-readable instructions further cause the processors to: sign the data in the first ticket tracking data block with the cryptographic digital signature of the transferor entity identified in the holder identifier stored in the previous ticket tracking data block in response to confirmation of payment from the first transferee entity to the transferor entity; and sign the data in the second ticket tracking data block with the cryptographic digital signature of the first transferee entity identified in the holder identifier stored in the first ticket tracking data block in response to confirmation of payment from the second transferee entity to the first transferee entity.
 14. A computer-readable storage medium comprising computer-usable instructions that, when executed by at least one processor, cause the at least one processor to perform operations comprising: generating, by an issuer entity, a first ticket tracking data block on a ticket tracking data blockchain, the first ticket tracking data block storing a unique code value for the ticket, a holder identifier for identifying a holder of the ticket and a used indicator, where holder identifier is set to an identifier of the issuer entity for the ticket and the used indicator is set to a false state; signing data in the first ticket tracking data block with a first cryptographic digital signature of the issuer entity; generating, by a first transferee entity, a second ticket tracking data block on the ticket tracking data blockchain, the second ticket tracking data block storing a holder identifier, the unique code value for the ticket, and a used indicator, where the holder identifier is set to an identifier of the first transferee entity and the used indicator is set to the false state; linking the second ticket tracking data block to the first ticket tracking data block; and signing data in the second ticket tracking data block with a second cryptographic digital signature of the issuer entity.
 15. The computer-readable storage medium of claim 14, the operations further comprising: if the used indicator is set to the false state, generating, by a second transferee entity, a third ticket tracking data block on the ticket tracking data blockchain, the third ticket tracking data block storing a holder identifier, the unique code value for the ticket, and a used indicator, where the holder identifier is set to an identifier of the second transferee entity and the used indicator is set to the false state; linking the third ticket tracking data block to the second ticket tracking data block; and signing data in the third ticket tracking data block with a cryptographic digital signature of the first transferee entity.
 16. The computer-readable storage medium of claim 15, the operations further comprising: receiving from the second transferee entity a presented code value; and if the used indicator stored in the third ticket tracking data block is set to the false state and the presented code value corresponds to the unique code value stored in the third ticket tracking data block, indicating the ticket as valid and setting the used indicator to the true state.
 17. The computer-readable storage medium of claim 15, where: the second ticket tracking data block stores a price value and the price value is set to a first transfer price for the transfer from the issuer entity to the first transferee entity; and the generating, by the second transferee entity, the third ticket tracking data block on the ticket tracking data blockchain includes determining whether a second transfer price for the transfer from the first transferee entity to the second transferee entity is greater than the first transfer price, and if the second transfer price is greater than the first transfer price, send a payment from the first transferee to the issuer entity.
 18. The computer-readable storage medium of claim 17, where an amount of the payment from the first transferee to the issuer entity comprises at least one of a predetermined amount, an amount based on the second transfer price, and an amount based on a difference between the first and second transfer prices.
 19. The computer-readable storage medium of claim 15, where: the identifier of the issuer entity comprises a public key address for the issuer entity; the identifier of the first transferee entity comprises a public key address for the first transferee entity; the identifier of the second transferee entity comprises a public key address for the second transferee entity; the first cryptographic digital signature of the issuer entity is partially based on data within the first ticket tracking data block; the second cryptographic digital signature of the issuer entity is partially based on data within the second ticket tracking data block; and the cryptographic digital signature of the first transferee entity is partially based on data within the third ticket tracking data block.
 20. The computer-readable storage medium of claim 15, where: the signing the data in the second ticket tracking data block with the second cryptographic digital signature of the issuer entity is performed in response to confirmation of payment from the first transferee entity to the issuer entity; and the signing the data in the third ticket tracking data block with the cryptographic digital signature of the first transferee entity is performed in response to confirmation of payment from the second transferee entity to the first transferee entity. 